From xen-devel-bounces@lists.xen.org Wed Aug 01 00:00:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 00:00:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwMLu-0004UD-Id; Tue, 31 Jul 2012 23:59:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwMLt-0004U8-SB for xen-devel@lists.xen.org; Tue, 31 Jul 2012 23:59:50 +0000 Received: from [85.158.139.83:50347] by server-4.bemta-5.messagelabs.com id BA/37-27831-47178105; Tue, 31 Jul 2012 23:59:48 +0000 X-Env-Sender: lists+xen@internecto.net X-Msg-Ref: server-2.tower-182.messagelabs.com!1343779188!29618397!1 X-Originating-IP: [176.9.245.29] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17018 invoked from network); 31 Jul 2012 23:59:48 -0000 Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29) by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Jul 2012 23:59:48 -0000 Received: from localhost (unknown [127.0.0.1]) by mx1.internecto.net (Postfix) with ESMTP id EEB52A02F0; Tue, 31 Jul 2012 23:59:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.internecto.net Received: from mx1.internecto.net ([127.0.0.1]) by localhost (mail.polaris.internecto.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu8ExOIE6eOM; Tue, 31 Jul 2012 23:59:42 +0000 (UTC) Received: from internecto.net (5ED4FDEB.cm-7-5d.dynamic.ziggo.nl [94.212.253.235]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: lists@internecto.net) by mx1.internecto.net (Postfix) with ESMTPSA id 9E1C1A02EC; Tue, 31 Jul 2012 23:59:42 +0000 (UTC) Date: Wed, 1 Aug 2012 01:59:41 +0200 From: Mark van Dijk To: Konrad Rzeszutek Wilk Message-ID: <20120801015941.22f773d3@internecto.net> In-Reply-To: <20120731134054.GD4789@phenom.dumpdata.com> References: <20120722181611.7ae03506@internecto.net> <20120723142025.GB793@phenom.dumpdata.com> <20120726022527.4d3f6e4a@internecto.net> <20120726140552.GD28024@phenom.dumpdata.com> <501176DD0200007800090A32@nat28.tlf.novell.com> <20120726145535.GA5743@phenom.dumpdata.com> <20120728145515.50bf4d45@internecto.net> <501657C70200007800091357@nat28.tlf.novell.com> <20120731134054.GD4789@phenom.dumpdata.com> Organization: Internecto SIS X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; i686-pc-linux-gnu) Mime-Version: 1.0 Cc: Jan Beulich , xen-devel@lists.xen.org Subject: Re: [Xen-devel] Kernel crash with acpi_processor, cpu_idle and intel_idle =y X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Message 20120731134054.GD4789@phenom.dumpdata.com contained: >Duh! That is easy enough to fix. Mark, can you please try testing with >this patch (and obviously enable the CONFIG_INTEL_IDLE) > >diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c >index d0f59c3..46a9884 100644 >--- a/drivers/idle/intel_idle.c >+++ b/drivers/idle/intel_idle.c >@@ -557,7 +557,7 @@ static int __init intel_idle_init(void) > retval = cpuidle_register_driver(&intel_idle_driver); > if (retval) { > printk(KERN_DEBUG PREFIX "intel_idle yielding to %s", >- cpuidle_get_driver()->name); >+ cpuidle_get_driver() ? >cpuidle_get_driver()->name : "none"); > return retval; > } > Good going Jan and Konrad. The above patch works: no more crashes. For fun I have also tested the patch from my previous email (the link to the lkml, it has been acked so was worth a try). I tested it in correlation with your patch and I still see no crashes. -- Stay in touch, Mark van Dijk. ,-------------------------------- ----------------------------' Tue Jul 31 22:19 UTC 2012 Today is Pungenday, the 67th day of Confusion in the YOLD 3178 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 00:00:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 00:00:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwMLu-0004UD-Id; Tue, 31 Jul 2012 23:59:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwMLt-0004U8-SB for xen-devel@lists.xen.org; Tue, 31 Jul 2012 23:59:50 +0000 Received: from [85.158.139.83:50347] by server-4.bemta-5.messagelabs.com id BA/37-27831-47178105; Tue, 31 Jul 2012 23:59:48 +0000 X-Env-Sender: lists+xen@internecto.net X-Msg-Ref: server-2.tower-182.messagelabs.com!1343779188!29618397!1 X-Originating-IP: [176.9.245.29] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17018 invoked from network); 31 Jul 2012 23:59:48 -0000 Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29) by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Jul 2012 23:59:48 -0000 Received: from localhost (unknown [127.0.0.1]) by mx1.internecto.net (Postfix) with ESMTP id EEB52A02F0; Tue, 31 Jul 2012 23:59:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.internecto.net Received: from mx1.internecto.net ([127.0.0.1]) by localhost (mail.polaris.internecto.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu8ExOIE6eOM; Tue, 31 Jul 2012 23:59:42 +0000 (UTC) Received: from internecto.net (5ED4FDEB.cm-7-5d.dynamic.ziggo.nl [94.212.253.235]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: lists@internecto.net) by mx1.internecto.net (Postfix) with ESMTPSA id 9E1C1A02EC; Tue, 31 Jul 2012 23:59:42 +0000 (UTC) Date: Wed, 1 Aug 2012 01:59:41 +0200 From: Mark van Dijk To: Konrad Rzeszutek Wilk Message-ID: <20120801015941.22f773d3@internecto.net> In-Reply-To: <20120731134054.GD4789@phenom.dumpdata.com> References: <20120722181611.7ae03506@internecto.net> <20120723142025.GB793@phenom.dumpdata.com> <20120726022527.4d3f6e4a@internecto.net> <20120726140552.GD28024@phenom.dumpdata.com> <501176DD0200007800090A32@nat28.tlf.novell.com> <20120726145535.GA5743@phenom.dumpdata.com> <20120728145515.50bf4d45@internecto.net> <501657C70200007800091357@nat28.tlf.novell.com> <20120731134054.GD4789@phenom.dumpdata.com> Organization: Internecto SIS X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; i686-pc-linux-gnu) Mime-Version: 1.0 Cc: Jan Beulich , xen-devel@lists.xen.org Subject: Re: [Xen-devel] Kernel crash with acpi_processor, cpu_idle and intel_idle =y X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Message 20120731134054.GD4789@phenom.dumpdata.com contained: >Duh! That is easy enough to fix. Mark, can you please try testing with >this patch (and obviously enable the CONFIG_INTEL_IDLE) > >diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c >index d0f59c3..46a9884 100644 >--- a/drivers/idle/intel_idle.c >+++ b/drivers/idle/intel_idle.c >@@ -557,7 +557,7 @@ static int __init intel_idle_init(void) > retval = cpuidle_register_driver(&intel_idle_driver); > if (retval) { > printk(KERN_DEBUG PREFIX "intel_idle yielding to %s", >- cpuidle_get_driver()->name); >+ cpuidle_get_driver() ? >cpuidle_get_driver()->name : "none"); > return retval; > } > Good going Jan and Konrad. The above patch works: no more crashes. For fun I have also tested the patch from my previous email (the link to the lkml, it has been acked so was worth a try). I tested it in correlation with your patch and I still see no crashes. -- Stay in touch, Mark van Dijk. ,-------------------------------- ----------------------------' Tue Jul 31 22:19 UTC 2012 Today is Pungenday, the 67th day of Confusion in the YOLD 3178 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 00:05:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 00:05:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwMQY-00059n-9r; Wed, 01 Aug 2012 00:04:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwMQW-00059g-EX for xen-devel@lists.xen.org; Wed, 01 Aug 2012 00:04:36 +0000 Received: from [85.158.143.35:36778] by server-2.bemta-4.messagelabs.com id D9/CB-17938-39278105; Wed, 01 Aug 2012 00:04:35 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1343779473!4969469!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDY3MTAxNw==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7759 invoked from network); 1 Aug 2012 00:04:35 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Aug 2012 00:04:35 -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 q7104RbQ014343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Aug 2012 00:04:28 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 q7104RQ0018617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 00:04:27 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 q7104Quk009031; Tue, 31 Jul 2012 19:04:26 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 31 Jul 2012 17:04:26 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 7BB0F402B2; Tue, 31 Jul 2012 19:55:27 -0400 (EDT) Date: Tue, 31 Jul 2012 19:55:27 -0400 From: Konrad Rzeszutek Wilk To: Mark van Dijk Message-ID: <20120731235527.GM32698@phenom.dumpdata.com> References: <20120722181611.7ae03506@internecto.net> <20120723142025.GB793@phenom.dumpdata.com> <20120726022527.4d3f6e4a@internecto.net> <20120726140552.GD28024@phenom.dumpdata.com> <501176DD0200007800090A32@nat28.tlf.novell.com> <20120726145535.GA5743@phenom.dumpdata.com> <20120728145515.50bf4d45@internecto.net> <501657C70200007800091357@nat28.tlf.novell.com> <20120731134054.GD4789@phenom.dumpdata.com> <20120801015941.22f773d3@internecto.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120801015941.22f773d3@internecto.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Jan Beulich , xen-devel@lists.xen.org Subject: Re: [Xen-devel] Kernel crash with acpi_processor, cpu_idle and intel_idle =y X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Aug 01, 2012 at 01:59:41AM +0200, Mark van Dijk wrote: > Message 20120731134054.GD4789@phenom.dumpdata.com contained: > > >Duh! That is easy enough to fix. Mark, can you please try testing with > >this patch (and obviously enable the CONFIG_INTEL_IDLE) > > > >diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c > >index d0f59c3..46a9884 100644 > >--- a/drivers/idle/intel_idle.c > >+++ b/drivers/idle/intel_idle.c > >@@ -557,7 +557,7 @@ static int __init intel_idle_init(void) > > retval = cpuidle_register_driver(&intel_idle_driver); > > if (retval) { > > printk(KERN_DEBUG PREFIX "intel_idle yielding to %s", > >- cpuidle_get_driver()->name); > >+ cpuidle_get_driver() ? > >cpuidle_get_driver()->name : "none"); > > return retval; > > } > > > > Good going Jan and Konrad. The above patch works: no more crashes. For > fun I have also tested the patch from my previous email (the link to > the lkml, it has been acked so was worth a try). I tested it in > correlation with your patch and I still see no crashes. Ok, is it Ok if I include your name as Reported-by and Tested-by? Thx > > > > -- > Stay in touch, > Mark van Dijk. ,-------------------------------- > ----------------------------' Tue Jul 31 22:19 UTC 2012 > Today is Pungenday, the 67th day of Confusion in the YOLD 3178 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 00:05:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 00:05:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwMQY-00059n-9r; Wed, 01 Aug 2012 00:04:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwMQW-00059g-EX for xen-devel@lists.xen.org; Wed, 01 Aug 2012 00:04:36 +0000 Received: from [85.158.143.35:36778] by server-2.bemta-4.messagelabs.com id D9/CB-17938-39278105; Wed, 01 Aug 2012 00:04:35 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1343779473!4969469!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDY3MTAxNw==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7759 invoked from network); 1 Aug 2012 00:04:35 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Aug 2012 00:04:35 -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 q7104RbQ014343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Aug 2012 00:04:28 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 q7104RQ0018617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 00:04:27 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 q7104Quk009031; Tue, 31 Jul 2012 19:04:26 -0500 Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 31 Jul 2012 17:04:26 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 7BB0F402B2; Tue, 31 Jul 2012 19:55:27 -0400 (EDT) Date: Tue, 31 Jul 2012 19:55:27 -0400 From: Konrad Rzeszutek Wilk To: Mark van Dijk Message-ID: <20120731235527.GM32698@phenom.dumpdata.com> References: <20120722181611.7ae03506@internecto.net> <20120723142025.GB793@phenom.dumpdata.com> <20120726022527.4d3f6e4a@internecto.net> <20120726140552.GD28024@phenom.dumpdata.com> <501176DD0200007800090A32@nat28.tlf.novell.com> <20120726145535.GA5743@phenom.dumpdata.com> <20120728145515.50bf4d45@internecto.net> <501657C70200007800091357@nat28.tlf.novell.com> <20120731134054.GD4789@phenom.dumpdata.com> <20120801015941.22f773d3@internecto.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120801015941.22f773d3@internecto.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Jan Beulich , xen-devel@lists.xen.org Subject: Re: [Xen-devel] Kernel crash with acpi_processor, cpu_idle and intel_idle =y X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Aug 01, 2012 at 01:59:41AM +0200, Mark van Dijk wrote: > Message 20120731134054.GD4789@phenom.dumpdata.com contained: > > >Duh! That is easy enough to fix. Mark, can you please try testing with > >this patch (and obviously enable the CONFIG_INTEL_IDLE) > > > >diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c > >index d0f59c3..46a9884 100644 > >--- a/drivers/idle/intel_idle.c > >+++ b/drivers/idle/intel_idle.c > >@@ -557,7 +557,7 @@ static int __init intel_idle_init(void) > > retval = cpuidle_register_driver(&intel_idle_driver); > > if (retval) { > > printk(KERN_DEBUG PREFIX "intel_idle yielding to %s", > >- cpuidle_get_driver()->name); > >+ cpuidle_get_driver() ? > >cpuidle_get_driver()->name : "none"); > > return retval; > > } > > > > Good going Jan and Konrad. The above patch works: no more crashes. For > fun I have also tested the patch from my previous email (the link to > the lkml, it has been acked so was worth a try). I tested it in > correlation with your patch and I still see no crashes. Ok, is it Ok if I include your name as Reported-by and Tested-by? Thx > > > > -- > Stay in touch, > Mark van Dijk. ,-------------------------------- > ----------------------------' Tue Jul 31 22:19 UTC 2012 > Today is Pungenday, the 67th day of Confusion in the YOLD 3178 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 00:20:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 00: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 1SwMfW-0005WC-D7; Wed, 01 Aug 2012 00:20:06 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwMfU-0005W7-J9 for xen-devel@lists.xensource.com; Wed, 01 Aug 2012 00:20:04 +0000 Received: from [85.158.138.51:17911] by server-1.bemta-3.messagelabs.com id 42/4F-31934-33678105; Wed, 01 Aug 2012 00:20:03 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1343780403!9519046!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDc2Mjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9441 invoked from network); 1 Aug 2012 00:20: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; 1 Aug 2012 00:20:03 -0000 X-IronPort-AV: E=Sophos;i="4.77,690,1336348800"; d="scan'208";a="13792857" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Aug 2012 00:20:02 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Aug 2012 01:20:02 +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 1SwMfS-0008OE-Ig; Wed, 01 Aug 2012 00:20:02 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SwMfS-0001i5-Ha; Wed, 01 Aug 2012 01:20:02 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 1 Aug 2012 01:20:02 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 13528: 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 13528 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13528/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 8 debian-fixup fail pass in 13524 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail pass in 13524 test-i386-i386-xl-win 5 xen-boot fail in 13524 pass in 13528 test-amd64-i386-xl-win7-amd64 7 windows-install fail in 13524 pass in 13528 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail like 13514 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 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-multivcpu 15 guest-stop fail never pass test-amd64-amd64-xl-sedf-pin 15 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-i386-i386-xl-win 7 windows-install fail never pass test-amd64-amd64-xl-winxpsp3 7 windows-install fail never pass test-i386-i386-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-i386-xl-win7-amd64 8 guest-saverestore fail never pass test-i386-i386-xl-winxpsp3 7 windows-install fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-win 7 windows-install fail never pass test-amd64-amd64-xl-sedf 15 guest-stop fail in 13524 never pass test-amd64-i386-xl-credit2 15 guest-stop fail in 13524 never pass test-amd64-i386-xl-win-vcpus1 7 windows-install fail in 13524 never pass version targeted for testing: xen 6d7ae840463c baseline version: xen 82fcf3a5dc3a ------------------------------------------------------------ People who touched revisions under test: Ian Jackson Jan Beulich Joe Jin Keir Fraser Yang Zhang ------------------------------------------------------------ jobs: build-amd64 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=6d7ae840463c + . 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 6d7ae840463c + branch=xen-4.0-testing + revision=6d7ae840463c + . 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 6d7ae840463c ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 3 changesets with 3 changes to 3 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 00:20:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 00: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 1SwMfW-0005WC-D7; Wed, 01 Aug 2012 00:20:06 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwMfU-0005W7-J9 for xen-devel@lists.xensource.com; Wed, 01 Aug 2012 00:20:04 +0000 Received: from [85.158.138.51:17911] by server-1.bemta-3.messagelabs.com id 42/4F-31934-33678105; Wed, 01 Aug 2012 00:20:03 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1343780403!9519046!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDc2Mjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9441 invoked from network); 1 Aug 2012 00:20: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; 1 Aug 2012 00:20:03 -0000 X-IronPort-AV: E=Sophos;i="4.77,690,1336348800"; d="scan'208";a="13792857" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Aug 2012 00:20:02 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Aug 2012 01:20:02 +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 1SwMfS-0008OE-Ig; Wed, 01 Aug 2012 00:20:02 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SwMfS-0001i5-Ha; Wed, 01 Aug 2012 01:20:02 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 1 Aug 2012 01:20:02 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.0-testing test] 13528: 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 13528 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13528/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 8 debian-fixup fail pass in 13524 test-amd64-i386-xl-win-vcpus1 5 xen-boot fail pass in 13524 test-i386-i386-xl-win 5 xen-boot fail in 13524 pass in 13528 test-amd64-i386-xl-win7-amd64 7 windows-install fail in 13524 pass in 13528 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail like 13514 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 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-multivcpu 15 guest-stop fail never pass test-amd64-amd64-xl-sedf-pin 15 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 8 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-install fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-i386-i386-xl-win 7 windows-install fail never pass test-amd64-amd64-xl-winxpsp3 7 windows-install fail never pass test-i386-i386-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-i386-xl-win7-amd64 8 guest-saverestore fail never pass test-i386-i386-xl-winxpsp3 7 windows-install fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-win 7 windows-install fail never pass test-amd64-amd64-xl-sedf 15 guest-stop fail in 13524 never pass test-amd64-i386-xl-credit2 15 guest-stop fail in 13524 never pass test-amd64-i386-xl-win-vcpus1 7 windows-install fail in 13524 never pass version targeted for testing: xen 6d7ae840463c baseline version: xen 82fcf3a5dc3a ------------------------------------------------------------ People who touched revisions under test: Ian Jackson Jan Beulich Joe Jin Keir Fraser Yang Zhang ------------------------------------------------------------ jobs: build-amd64 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=6d7ae840463c + . 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 6d7ae840463c + branch=xen-4.0-testing + revision=6d7ae840463c + . 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 6d7ae840463c ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 3 changesets with 3 changes to 3 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 00:26:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 00: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 1SwMkl-0005lb-Fo; Wed, 01 Aug 2012 00:25:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwMkj-0005lV-AA for xen-devel@lists.xen.org; Wed, 01 Aug 2012 00:25:29 +0000 Received: from [85.158.139.83:6627] by server-7.bemta-5.messagelabs.com id F4/4E-28276-87778105; Wed, 01 Aug 2012 00:25:28 +0000 X-Env-Sender: lists+xen@internecto.net X-Msg-Ref: server-5.tower-182.messagelabs.com!1343780727!29683820!1 X-Originating-IP: [176.9.245.29] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9608 invoked from network); 1 Aug 2012 00:25:27 -0000 Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29) by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Aug 2012 00:25:27 -0000 Received: from localhost (unknown [127.0.0.1]) by mx1.internecto.net (Postfix) with ESMTP id 46321A02F0; Wed, 1 Aug 2012 00:25:27 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.internecto.net Received: from mx1.internecto.net ([127.0.0.1]) by localhost (mail.polaris.internecto.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLlHB3+0za8t; Wed, 1 Aug 2012 00:25:20 +0000 (UTC) Received: from internecto.net (5ED4FDEB.cm-7-5d.dynamic.ziggo.nl [94.212.253.235]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: lists@internecto.net) by mx1.internecto.net (Postfix) with ESMTPSA id A5D30A02EC; Wed, 1 Aug 2012 00:25:20 +0000 (UTC) Date: Wed, 1 Aug 2012 02:25:18 +0200 From: Mark van Dijk To: Konrad Rzeszutek Wilk Message-ID: <20120801022518.212fc429@internecto.net> In-Reply-To: <20120731235527.GM32698@phenom.dumpdata.com> References: <20120722181611.7ae03506@internecto.net> <20120723142025.GB793@phenom.dumpdata.com> <20120726022527.4d3f6e4a@internecto.net> <20120726140552.GD28024@phenom.dumpdata.com> <501176DD0200007800090A32@nat28.tlf.novell.com> <20120726145535.GA5743@phenom.dumpdata.com> <20120728145515.50bf4d45@internecto.net> <501657C70200007800091357@nat28.tlf.novell.com> <20120731134054.GD4789@phenom.dumpdata.com> <20120801015941.22f773d3@internecto.net> <20120731235527.GM32698@phenom.dumpdata.com> Organization: Internecto SIS X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; i686-pc-linux-gnu) Mime-Version: 1.0 Cc: Jan Beulich , xen-devel@lists.xen.org Subject: Re: [Xen-devel] Kernel crash with acpi_processor, cpu_idle and intel_idle =y X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Message 20120731235527.GM32698@phenom.dumpdata.com contained: >Ok, is it Ok if I include your name as Reported-by and Tested-by? Yes, that's fine. Thanks for asking. If you want to include my email address please substitute 'lists+xen' with 'mark'. -- Stay in touch, Mark van Dijk. ,-------------------------------- ----------------------------' Wed Aug 01 00:22 UTC 2012 Today is Pungenday, the 67th day of Confusion in the YOLD 3178 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 00:26:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 00: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 1SwMkl-0005lb-Fo; Wed, 01 Aug 2012 00:25:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwMkj-0005lV-AA for xen-devel@lists.xen.org; Wed, 01 Aug 2012 00:25:29 +0000 Received: from [85.158.139.83:6627] by server-7.bemta-5.messagelabs.com id F4/4E-28276-87778105; Wed, 01 Aug 2012 00:25:28 +0000 X-Env-Sender: lists+xen@internecto.net X-Msg-Ref: server-5.tower-182.messagelabs.com!1343780727!29683820!1 X-Originating-IP: [176.9.245.29] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9608 invoked from network); 1 Aug 2012 00:25:27 -0000 Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29) by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Aug 2012 00:25:27 -0000 Received: from localhost (unknown [127.0.0.1]) by mx1.internecto.net (Postfix) with ESMTP id 46321A02F0; Wed, 1 Aug 2012 00:25:27 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.internecto.net Received: from mx1.internecto.net ([127.0.0.1]) by localhost (mail.polaris.internecto.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLlHB3+0za8t; Wed, 1 Aug 2012 00:25:20 +0000 (UTC) Received: from internecto.net (5ED4FDEB.cm-7-5d.dynamic.ziggo.nl [94.212.253.235]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: lists@internecto.net) by mx1.internecto.net (Postfix) with ESMTPSA id A5D30A02EC; Wed, 1 Aug 2012 00:25:20 +0000 (UTC) Date: Wed, 1 Aug 2012 02:25:18 +0200 From: Mark van Dijk To: Konrad Rzeszutek Wilk Message-ID: <20120801022518.212fc429@internecto.net> In-Reply-To: <20120731235527.GM32698@phenom.dumpdata.com> References: <20120722181611.7ae03506@internecto.net> <20120723142025.GB793@phenom.dumpdata.com> <20120726022527.4d3f6e4a@internecto.net> <20120726140552.GD28024@phenom.dumpdata.com> <501176DD0200007800090A32@nat28.tlf.novell.com> <20120726145535.GA5743@phenom.dumpdata.com> <20120728145515.50bf4d45@internecto.net> <501657C70200007800091357@nat28.tlf.novell.com> <20120731134054.GD4789@phenom.dumpdata.com> <20120801015941.22f773d3@internecto.net> <20120731235527.GM32698@phenom.dumpdata.com> Organization: Internecto SIS X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; i686-pc-linux-gnu) Mime-Version: 1.0 Cc: Jan Beulich , xen-devel@lists.xen.org Subject: Re: [Xen-devel] Kernel crash with acpi_processor, cpu_idle and intel_idle =y X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Message 20120731235527.GM32698@phenom.dumpdata.com contained: >Ok, is it Ok if I include your name as Reported-by and Tested-by? Yes, that's fine. Thanks for asking. If you want to include my email address please substitute 'lists+xen' with 'mark'. -- Stay in touch, Mark van Dijk. ,-------------------------------- ----------------------------' Wed Aug 01 00:22 UTC 2012 Today is Pungenday, the 67th day of Confusion in the YOLD 3178 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 02:52:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 02:52:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwP2J-0001t6-8D; Wed, 01 Aug 2012 02:51:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwP2H-0001sy-IY for xen-devel@lists.xensource.com; Wed, 01 Aug 2012 02:51:45 +0000 Received: from [85.158.143.99:63458] by server-1.bemta-4.messagelabs.com id A9/F2-24392-0C998105; Wed, 01 Aug 2012 02:51:44 +0000 X-Env-Sender: shakeel.butt@gmail.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1343789504!17989458!1 X-Originating-IP: [209.85.215.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2038 invoked from network); 1 Aug 2012 02:51:44 -0000 Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com) (209.85.215.171) by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 1 Aug 2012 02:51:44 -0000 Received: by eaal12 with SMTP id l12so843977eaa.30 for ; Tue, 31 Jul 2012 19:51:43 -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=171nj3Xpeg56l3ss52pTMoNOL7hb0CIqVoUGMRXCMC8=; b=uJ00rDdZHl2TzrYWNE87x8JUyH7sIHw2DMg5EcJTWD+N8GMuLs2GUO0fRTKYn0UNmc 0rz9D6vqT1nqe3jRZXI6jDpCDPfjUCyGpM51M0elrffr35Cc9nFuCGzBz9P+6naWihPi rnzV2MMiJOntK/Y+iv4qIy+1bv6FB1XJAY5LYVv2DZGSSlJzY7xX98yi/KbEyeHHxHnU qhOKXXLKUgAQlDvqXolcJq/x2skm8NKTt5htA8wnBS3hD+/zXPLBo+wnDdSd2jiX62wP yCH62RMT/MTfFaVFUDjALXyn9aquc4VOAj5ngKM7VbJydl6P7zHDiAoMkPOVi5WCWkfM hr/g== MIME-Version: 1.0 Received: by 10.14.203.132 with SMTP id f4mr20648516eeo.24.1343789503850; Tue, 31 Jul 2012 19:51:43 -0700 (PDT) Received: by 10.14.94.200 with HTTP; Tue, 31 Jul 2012 19:51:43 -0700 (PDT) In-Reply-To: <5016E519.9080304@tycho.nsa.gov> References: <5016E519.9080304@tycho.nsa.gov> Date: Tue, 31 Jul 2012 22:51:43 -0400 Message-ID: From: Shakeel Butt To: Daniel De Graaf Cc: xen-devel Subject: Re: [Xen-devel] XSM instead of IS_PRIV X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > Once this is done, it will make sense to change the XSM header file so > that the appropriate xsm_* hooks resolve to IS_PRIV when XSM is not > enabled. This would allow the IS_PRIV hooks covered by XSM to be > completely removed, assuming the Xen developers agree that the XSM hooks > cover all all the important code. Thanks for replying. So, is there consensus among the Xen community to adopt this patch (xsm hooks replacing IS_PRIV) on upstream Xen? thanks, Shakeel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 02:52:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 02:52:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwP2J-0001t6-8D; Wed, 01 Aug 2012 02:51:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwP2H-0001sy-IY for xen-devel@lists.xensource.com; Wed, 01 Aug 2012 02:51:45 +0000 Received: from [85.158.143.99:63458] by server-1.bemta-4.messagelabs.com id A9/F2-24392-0C998105; Wed, 01 Aug 2012 02:51:44 +0000 X-Env-Sender: shakeel.butt@gmail.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1343789504!17989458!1 X-Originating-IP: [209.85.215.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2038 invoked from network); 1 Aug 2012 02:51:44 -0000 Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com) (209.85.215.171) by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 1 Aug 2012 02:51:44 -0000 Received: by eaal12 with SMTP id l12so843977eaa.30 for ; Tue, 31 Jul 2012 19:51:43 -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=171nj3Xpeg56l3ss52pTMoNOL7hb0CIqVoUGMRXCMC8=; b=uJ00rDdZHl2TzrYWNE87x8JUyH7sIHw2DMg5EcJTWD+N8GMuLs2GUO0fRTKYn0UNmc 0rz9D6vqT1nqe3jRZXI6jDpCDPfjUCyGpM51M0elrffr35Cc9nFuCGzBz9P+6naWihPi rnzV2MMiJOntK/Y+iv4qIy+1bv6FB1XJAY5LYVv2DZGSSlJzY7xX98yi/KbEyeHHxHnU qhOKXXLKUgAQlDvqXolcJq/x2skm8NKTt5htA8wnBS3hD+/zXPLBo+wnDdSd2jiX62wP yCH62RMT/MTfFaVFUDjALXyn9aquc4VOAj5ngKM7VbJydl6P7zHDiAoMkPOVi5WCWkfM hr/g== MIME-Version: 1.0 Received: by 10.14.203.132 with SMTP id f4mr20648516eeo.24.1343789503850; Tue, 31 Jul 2012 19:51:43 -0700 (PDT) Received: by 10.14.94.200 with HTTP; Tue, 31 Jul 2012 19:51:43 -0700 (PDT) In-Reply-To: <5016E519.9080304@tycho.nsa.gov> References: <5016E519.9080304@tycho.nsa.gov> Date: Tue, 31 Jul 2012 22:51:43 -0400 Message-ID: From: Shakeel Butt To: Daniel De Graaf Cc: xen-devel Subject: Re: [Xen-devel] XSM instead of IS_PRIV X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > Once this is done, it will make sense to change the XSM header file so > that the appropriate xsm_* hooks resolve to IS_PRIV when XSM is not > enabled. This would allow the IS_PRIV hooks covered by XSM to be > completely removed, assuming the Xen developers agree that the XSM hooks > cover all all the important code. Thanks for replying. So, is there consensus among the Xen community to adopt this patch (xsm hooks replacing IS_PRIV) on upstream Xen? thanks, Shakeel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 04:31:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 04: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 1SwQaJ-0002tG-Sh; Wed, 01 Aug 2012 04:30:59 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwLYR-0003gy-RZ for xen-devel@lists.xen.org; Tue, 31 Jul 2012 23:08:43 +0000 Received: from [85.158.138.51:16643] by server-10.bemta-3.messagelabs.com id 13/06-21993-A7568105; Tue, 31 Jul 2012 23:08:42 +0000 X-Env-Sender: lmw@satx.rr.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1343776121!20250725!1 X-Originating-IP: [75.180.132.120] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA3NS4xODAuMTMyLjEyMCA9PiA5ODA3NQ==\n,sa_preprocessor: QmFkIElQOiA3NS4xODAuMTMyLjEyMCA9PiA5ODA3NQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12580 invoked from network); 31 Jul 2012 23:08:42 -0000 Received: from cdptpa-omtalb.mail.rr.com (HELO cdptpa-omtalb.mail.rr.com) (75.180.132.120) by server-12.tower-174.messagelabs.com with SMTP; 31 Jul 2012 23:08:42 -0000 Authentication-Results: cdptpa-omtalb.mail.rr.com smtp.user=lmw@satx.rr.com; auth=pass (LOGIN) X-Authority-Analysis: v=2.0 cv=IuCcgcDg c=1 sm=0 a=05ChyHeVI94A:10 a=IkcTkHD0fZMA:10 a=ayC55rCoAAAA:8 a=VZa10c6xo_XutLS05KUA:9 a=QEXdDO2ut3YA:10 a=FXLSPIJfNss/Zw1CXsBq9w==:117 X-Cloudmark-Score: 0 Received: from [10.127.132.171] ([10.127.132.171:56289] helo=cdptpa-web20-z02) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTPA id 81/00-17657-97568105; Tue, 31 Jul 2012 23:08:41 +0000 Message-ID: <20120731230841.M5H9R.154709.root@cdptpa-web20-z02> Date: Tue, 31 Jul 2012 23:08:41 +0000 From: To: xen-devel@lists.xen.org MIME-Version: 1.0 X-Priority: 3 (Normal) Sensitivity: Normal X-Originating-IP: X-Mailman-Approved-At: Wed, 01 Aug 2012 04:30:59 +0000 Subject: [Xen-devel] serial="pty" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: 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 adding the keyword serial="pty" to a xen cfg file, I am able to open /dev/ttyS0 in my dom-U linux kernel environment and send serial data to a /dev/pts/x port in my dom-0 linux environment. If I happen to have have multiple dom-U's configured this way, what is the best way to determine how these ports will be mapped so I will know which /dev/pts port belongs to which dom-U's /dev/ttyS0 port? Thanks, Larry White _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 04:31:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 04: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 1SwQaJ-0002tG-Sh; Wed, 01 Aug 2012 04:30:59 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwLYR-0003gy-RZ for xen-devel@lists.xen.org; Tue, 31 Jul 2012 23:08:43 +0000 Received: from [85.158.138.51:16643] by server-10.bemta-3.messagelabs.com id 13/06-21993-A7568105; Tue, 31 Jul 2012 23:08:42 +0000 X-Env-Sender: lmw@satx.rr.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1343776121!20250725!1 X-Originating-IP: [75.180.132.120] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA3NS4xODAuMTMyLjEyMCA9PiA5ODA3NQ==\n,sa_preprocessor: QmFkIElQOiA3NS4xODAuMTMyLjEyMCA9PiA5ODA3NQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12580 invoked from network); 31 Jul 2012 23:08:42 -0000 Received: from cdptpa-omtalb.mail.rr.com (HELO cdptpa-omtalb.mail.rr.com) (75.180.132.120) by server-12.tower-174.messagelabs.com with SMTP; 31 Jul 2012 23:08:42 -0000 Authentication-Results: cdptpa-omtalb.mail.rr.com smtp.user=lmw@satx.rr.com; auth=pass (LOGIN) X-Authority-Analysis: v=2.0 cv=IuCcgcDg c=1 sm=0 a=05ChyHeVI94A:10 a=IkcTkHD0fZMA:10 a=ayC55rCoAAAA:8 a=VZa10c6xo_XutLS05KUA:9 a=QEXdDO2ut3YA:10 a=FXLSPIJfNss/Zw1CXsBq9w==:117 X-Cloudmark-Score: 0 Received: from [10.127.132.171] ([10.127.132.171:56289] helo=cdptpa-web20-z02) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTPA id 81/00-17657-97568105; Tue, 31 Jul 2012 23:08:41 +0000 Message-ID: <20120731230841.M5H9R.154709.root@cdptpa-web20-z02> Date: Tue, 31 Jul 2012 23:08:41 +0000 From: To: xen-devel@lists.xen.org MIME-Version: 1.0 X-Priority: 3 (Normal) Sensitivity: Normal X-Originating-IP: X-Mailman-Approved-At: Wed, 01 Aug 2012 04:30:59 +0000 Subject: [Xen-devel] serial="pty" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: 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 adding the keyword serial="pty" to a xen cfg file, I am able to open /dev/ttyS0 in my dom-U linux kernel environment and send serial data to a /dev/pts/x port in my dom-0 linux environment. If I happen to have have multiple dom-U's configured this way, what is the best way to determine how these ports will be mapped so I will know which /dev/pts port belongs to which dom-U's /dev/ttyS0 port? Thanks, Larry White _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 04:31:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 04: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 1SwQaK-0002tU-LA; Wed, 01 Aug 2012 04:31:00 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwPQn-0002Va-55 for xen-devel@lists.xen.org; Wed, 01 Aug 2012 03:17:05 +0000 X-Env-Sender: tamas.k.lengyel@gmail.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1343791015!3197403!1 X-Originating-IP: [209.85.160.173] 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-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5869 invoked from network); 1 Aug 2012 03:16:57 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Aug 2012 03:16:57 -0000 Received: by ghrr14 with SMTP id r14so7569247ghr.32 for ; Tue, 31 Jul 2012 20:16: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=TmdQUIdOm+0Gcg2PCFtQUccf9aQ0Qsj+aT5oEvl5xME=; b=AMEXvtdbw/sEGLooikPtsUmpHwmNsFxEpHH97nH+d7gAygAHvOgL80SE91V5So90c5 xnHbnOpXzBv5xe7ZRE/YyG8ypQeP5pZ/YM8ClnGnr4nDm3NvFNXgtxDohi4iD4HVkTCZ zzxknPSB4tprDy6WXpnX8vN14GzzDiwwIZyDs62YiQIyzg7pMnRkRLLuehUV0Ic3VfLO /filNbvFehWmvd/sSeEefQ6fNKsSD6+FkGknkmI6vjIC7BnRPdDe1IZafzSWM16sKbXz LFkXwNWPCKzHJ4qFvUjw9meesYG19PZGhyzMUpSMy/fqBkmrJePY9wlZzqwgYDzB+VAc NMJA== MIME-Version: 1.0 Received: by 10.50.202.68 with SMTP id kg4mr3909513igc.43.1343791015059; Tue, 31 Jul 2012 20:16:55 -0700 (PDT) Received: by 10.64.126.199 with HTTP; Tue, 31 Jul 2012 20:16:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 31 Jul 2012 23:16:55 -0400 Message-ID: From: Tamas Lengyel To: xen-devel@lists.xen.org X-Mailman-Approved-At: Wed, 01 Aug 2012 04:30:59 +0000 Subject: Re: [Xen-devel] libxl config datastructures X-BeenThere: xen-devel@lists.xen.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="===============0433309395694513612==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============0433309395694513612== Content-Type: multipart/alternative; boundary=f46d0447950b1ae12404c62bbacb --f46d0447950b1ae12404c62bbacb Content-Type: text/plain; charset=ISO-8859-1 Dear libxl developers, currently there is no way to automatically parse a config file into the libxl_domain_config datastructure and therefore using any libxl_* function that requires that datastructure as an input is unusable. The only implementation that creates that structure is in xl_cmdimpl.c in the private function parse_config_data. As I see, it relies on the XLU_Config structure to create the libxl_domain_config structure. It is very impractical to replicate that code for third party tools just to be able to use for example libxl_domain_restore. My requests is either: - Create a publicly accessible function in libxl.h that parses a file/char* to libxl_domain_config structure (essentially making parse_config_data public). - Or just use XLU_Config everywhere. I'm not entirely sure why there is a need to have two separate formats and the whole translation in-between. Thanks, Tamas --f46d0447950b1ae12404c62bbacb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear libxl developers,
currently there is no way to automatically parse a config file into the=A0l= ibxl_domain_config datastructure and therefore using any libxl_* function t= hat requires that datastructure as an input is unusable. The only implement= ation that creates that structure is in xl_cmdimpl.c in the private functio= n parse_config_data. As I see, it relies on the XLU_Config structure to cre= ate the libxl_domain_config structure. It is very=A0impractical to replicat= e that code for third party tools just to be able to use for example libxl_= domain_restore.=A0

My requests is either:
  • Create a publicly accessible function in libxl.h = that parses a file/char* to=A0libxl_domain_config structure (essentially ma= king parse_config_data public).
  • Or just use XLU_Config everywhere. I'm n= ot entirely sure why there is a need to have two separate formats and the w= hole translation=A0in-between.
Thanks,
Tamas
--f46d0447950b1ae12404c62bbacb-- --===============0433309395694513612== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0433309395694513612==-- From xen-devel-bounces@lists.xen.org Wed Aug 01 04:31:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 04: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 1SwQaK-0002tU-LA; Wed, 01 Aug 2012 04:31:00 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwPQn-0002Va-55 for xen-devel@lists.xen.org; Wed, 01 Aug 2012 03:17:05 +0000 X-Env-Sender: tamas.k.lengyel@gmail.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1343791015!3197403!1 X-Originating-IP: [209.85.160.173] 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-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5869 invoked from network); 1 Aug 2012 03:16:57 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Aug 2012 03:16:57 -0000 Received: by ghrr14 with SMTP id r14so7569247ghr.32 for ; Tue, 31 Jul 2012 20:16: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=TmdQUIdOm+0Gcg2PCFtQUccf9aQ0Qsj+aT5oEvl5xME=; b=AMEXvtdbw/sEGLooikPtsUmpHwmNsFxEpHH97nH+d7gAygAHvOgL80SE91V5So90c5 xnHbnOpXzBv5xe7ZRE/YyG8ypQeP5pZ/YM8ClnGnr4nDm3NvFNXgtxDohi4iD4HVkTCZ zzxknPSB4tprDy6WXpnX8vN14GzzDiwwIZyDs62YiQIyzg7pMnRkRLLuehUV0Ic3VfLO /filNbvFehWmvd/sSeEefQ6fNKsSD6+FkGknkmI6vjIC7BnRPdDe1IZafzSWM16sKbXz LFkXwNWPCKzHJ4qFvUjw9meesYG19PZGhyzMUpSMy/fqBkmrJePY9wlZzqwgYDzB+VAc NMJA== MIME-Version: 1.0 Received: by 10.50.202.68 with SMTP id kg4mr3909513igc.43.1343791015059; Tue, 31 Jul 2012 20:16:55 -0700 (PDT) Received: by 10.64.126.199 with HTTP; Tue, 31 Jul 2012 20:16:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 31 Jul 2012 23:16:55 -0400 Message-ID: From: Tamas Lengyel To: xen-devel@lists.xen.org X-Mailman-Approved-At: Wed, 01 Aug 2012 04:30:59 +0000 Subject: Re: [Xen-devel] libxl config datastructures X-BeenThere: xen-devel@lists.xen.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="===============0433309395694513612==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============0433309395694513612== Content-Type: multipart/alternative; boundary=f46d0447950b1ae12404c62bbacb --f46d0447950b1ae12404c62bbacb Content-Type: text/plain; charset=ISO-8859-1 Dear libxl developers, currently there is no way to automatically parse a config file into the libxl_domain_config datastructure and therefore using any libxl_* function that requires that datastructure as an input is unusable. The only implementation that creates that structure is in xl_cmdimpl.c in the private function parse_config_data. As I see, it relies on the XLU_Config structure to create the libxl_domain_config structure. It is very impractical to replicate that code for third party tools just to be able to use for example libxl_domain_restore. My requests is either: - Create a publicly accessible function in libxl.h that parses a file/char* to libxl_domain_config structure (essentially making parse_config_data public). - Or just use XLU_Config everywhere. I'm not entirely sure why there is a need to have two separate formats and the whole translation in-between. Thanks, Tamas --f46d0447950b1ae12404c62bbacb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear libxl developers,
currently there is no way to automatically parse a config file into the=A0l= ibxl_domain_config datastructure and therefore using any libxl_* function t= hat requires that datastructure as an input is unusable. The only implement= ation that creates that structure is in xl_cmdimpl.c in the private functio= n parse_config_data. As I see, it relies on the XLU_Config structure to cre= ate the libxl_domain_config structure. It is very=A0impractical to replicat= e that code for third party tools just to be able to use for example libxl_= domain_restore.=A0

My requests is either:
  • Create a publicly accessible function in libxl.h = that parses a file/char* to=A0libxl_domain_config structure (essentially ma= king parse_config_data public).
  • Or just use XLU_Config everywhere. I'm n= ot entirely sure why there is a need to have two separate formats and the w= hole translation=A0in-between.
Thanks,
Tamas
--f46d0447950b1ae12404c62bbacb-- --===============0433309395694513612== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0433309395694513612==-- From xen-devel-bounces@lists.xen.org Wed Aug 01 04:31:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 04: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 1SwQaK-0002tN-99; Wed, 01 Aug 2012 04:31:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwOwQ-0001s5-IO for xen-devel@lists.xen.org; Wed, 01 Aug 2012 02:45:42 +0000 Received: from [85.158.138.51:39789] by server-10.bemta-3.messagelabs.com id B4/7F-21993-55898105; Wed, 01 Aug 2012 02:45:41 +0000 X-Env-Sender: tamas.k.lengyel@gmail.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1343789139!28036830!1 X-Originating-IP: [209.85.213.45] 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-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11047 invoked from network); 1 Aug 2012 02:45:41 -0000 Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com) (209.85.213.45) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Aug 2012 02:45:41 -0000 Received: by yhpp34 with SMTP id p34so7589393yhp.32 for ; Tue, 31 Jul 2012 19:45:39 -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=eo5g3rWsFRrmOm9akwP0aKgSnoZlx+IUrhDBVZmeROI=; b=iNhsv84wXFtnngCwtgN5VZZF1l88m5JkuL/goNCMh0aMn4zTsDg2Hnjw0so7dbYWWQ fY6ybAglRaFLeodY1albG8JSJv+q+wR12EsD3oAtyVyb07TWhp8f/4vgx+Gb7UyKxxp+ +1egRguJ1lbAK4j3OzE0MGWNH3wVmTAtDpAP0Zoeohz2trjfv52Mwn9gLhkohxKmAiwi kxJqhchIUTys7lCAewEeEiICQ/6HhGT53u/8FBZKz5BcR3GBl6dvuk3ek7xc05YH+nH5 JQVg5B8uLAwhqMkOoZotEh0s693CnSUyrM8chF1hC4OG4vF9+Q0vIfz1lu2Ngs1zy3oB 4R6A== MIME-Version: 1.0 Received: by 10.50.185.129 with SMTP id fc1mr2585712igc.64.1343789139502; Tue, 31 Jul 2012 19:45:39 -0700 (PDT) Received: by 10.64.126.199 with HTTP; Tue, 31 Jul 2012 19:45:39 -0700 (PDT) Date: Tue, 31 Jul 2012 22:45:39 -0400 Message-ID: From: Tamas Lengyel To: xen-devel@lists.xen.org X-Mailman-Approved-At: Wed, 01 Aug 2012 04:30:59 +0000 Subject: [Xen-devel] libxl config datastructures X-BeenThere: xen-devel@lists.xen.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="===============6504664477599872048==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6504664477599872048== Content-Type: multipart/alternative; boundary=14dae934114350249b04c62b4a0e --14dae934114350249b04c62b4a0e Content-Type: text/plain; charset=ISO-8859-1 Dear libxl developers, currently there is no way to automatically parse a config file into the libxl_domain_config datastructure and therefore using any libxl_* function that requires that datastructure as an input is unusable. The only implementation that creates that structure is in xl_cmdimpl.c in the private function parse_config_data. As I see, it relies on the XLU_Config structure to create the libxl_domain_config structure. It is very impractical to replicate that code for third party tools just to be able to use for example libxl_domain_restore. My requests is either: - Create a publicly accessible function in libxl.h that parses a file/char* to libxl_domain_config structure (essentially making parse_config_data public). - Or just use XLU_Config everywhere. I'm not entirely sure why there is a need to have two separate formats and the whole translation in-between. Thanks, Tamas --14dae934114350249b04c62b4a0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear libxl developers,
currently there is no way to automatically parse= a config file into the=A0libxl_domain_config datastructure and therefore u= sing any libxl_* function that requires that datastructure as an input is u= nusable. The only implementation that creates that structure is in xl_cmdim= pl.c in the private function parse_config_data. As I see, it relies on the = XLU_Config structure to create the libxl_domain_config structure. It is ver= y=A0impractical to replicate that code for third party tools just to be abl= e to use for example libxl_domain_restore.=A0

My requests is either:
  • Create a publi= cly accessible function in libxl.h that parses a file/char* to=A0libxl_doma= in_config structure (essentially making parse_config_data public).
  • Or just use XLU_Config everywhere. I'm not entirely sure why there is a= need to have two separate formats and the whole translation=A0in-between.<= /li>
Thanks,
Tamas

--14dae934114350249b04c62b4a0e-- --===============6504664477599872048== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6504664477599872048==-- From xen-devel-bounces@lists.xen.org Wed Aug 01 04:31:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 04: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 1SwQaK-0002tN-99; Wed, 01 Aug 2012 04:31:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwOwQ-0001s5-IO for xen-devel@lists.xen.org; Wed, 01 Aug 2012 02:45:42 +0000 Received: from [85.158.138.51:39789] by server-10.bemta-3.messagelabs.com id B4/7F-21993-55898105; Wed, 01 Aug 2012 02:45:41 +0000 X-Env-Sender: tamas.k.lengyel@gmail.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1343789139!28036830!1 X-Originating-IP: [209.85.213.45] 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-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11047 invoked from network); 1 Aug 2012 02:45:41 -0000 Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com) (209.85.213.45) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Aug 2012 02:45:41 -0000 Received: by yhpp34 with SMTP id p34so7589393yhp.32 for ; Tue, 31 Jul 2012 19:45:39 -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=eo5g3rWsFRrmOm9akwP0aKgSnoZlx+IUrhDBVZmeROI=; b=iNhsv84wXFtnngCwtgN5VZZF1l88m5JkuL/goNCMh0aMn4zTsDg2Hnjw0so7dbYWWQ fY6ybAglRaFLeodY1albG8JSJv+q+wR12EsD3oAtyVyb07TWhp8f/4vgx+Gb7UyKxxp+ +1egRguJ1lbAK4j3OzE0MGWNH3wVmTAtDpAP0Zoeohz2trjfv52Mwn9gLhkohxKmAiwi kxJqhchIUTys7lCAewEeEiICQ/6HhGT53u/8FBZKz5BcR3GBl6dvuk3ek7xc05YH+nH5 JQVg5B8uLAwhqMkOoZotEh0s693CnSUyrM8chF1hC4OG4vF9+Q0vIfz1lu2Ngs1zy3oB 4R6A== MIME-Version: 1.0 Received: by 10.50.185.129 with SMTP id fc1mr2585712igc.64.1343789139502; Tue, 31 Jul 2012 19:45:39 -0700 (PDT) Received: by 10.64.126.199 with HTTP; Tue, 31 Jul 2012 19:45:39 -0700 (PDT) Date: Tue, 31 Jul 2012 22:45:39 -0400 Message-ID: From: Tamas Lengyel To: xen-devel@lists.xen.org X-Mailman-Approved-At: Wed, 01 Aug 2012 04:30:59 +0000 Subject: [Xen-devel] libxl config datastructures X-BeenThere: xen-devel@lists.xen.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="===============6504664477599872048==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6504664477599872048== Content-Type: multipart/alternative; boundary=14dae934114350249b04c62b4a0e --14dae934114350249b04c62b4a0e Content-Type: text/plain; charset=ISO-8859-1 Dear libxl developers, currently there is no way to automatically parse a config file into the libxl_domain_config datastructure and therefore using any libxl_* function that requires that datastructure as an input is unusable. The only implementation that creates that structure is in xl_cmdimpl.c in the private function parse_config_data. As I see, it relies on the XLU_Config structure to create the libxl_domain_config structure. It is very impractical to replicate that code for third party tools just to be able to use for example libxl_domain_restore. My requests is either: - Create a publicly accessible function in libxl.h that parses a file/char* to libxl_domain_config structure (essentially making parse_config_data public). - Or just use XLU_Config everywhere. I'm not entirely sure why there is a need to have two separate formats and the whole translation in-between. Thanks, Tamas --14dae934114350249b04c62b4a0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear libxl developers,
currently there is no way to automatically parse= a config file into the=A0libxl_domain_config datastructure and therefore u= sing any libxl_* function that requires that datastructure as an input is u= nusable. The only implementation that creates that structure is in xl_cmdim= pl.c in the private function parse_config_data. As I see, it relies on the = XLU_Config structure to create the libxl_domain_config structure. It is ver= y=A0impractical to replicate that code for third party tools just to be abl= e to use for example libxl_domain_restore.=A0

My requests is either:
  • Create a publi= cly accessible function in libxl.h that parses a file/char* to=A0libxl_doma= in_config structure (essentially making parse_config_data public).
  • Or just use XLU_Config everywhere. I'm not entirely sure why there is a= need to have two separate formats and the whole translation=A0in-between.<= /li>
Thanks,
Tamas

--14dae934114350249b04c62b4a0e-- --===============6504664477599872048== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6504664477599872048==-- From xen-devel-bounces@lists.xen.org Wed Aug 01 04:31:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 04: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 1SwQaJ-0002t9-HX; Wed, 01 Aug 2012 04:30:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwKKd-0002pf-3q for xen-devel@lists.xensource.com; Tue, 31 Jul 2012 21:50:23 +0000 Received: from [85.158.143.35:7474] by server-2.bemta-4.messagelabs.com id 65/A0-17938-D1358105; Tue, 31 Jul 2012 21:50:21 +0000 X-Env-Sender: anirbanchak@gmail.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1343771417!16207705!1 X-Originating-IP: [209.85.216.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14738 invoked from network); 31 Jul 2012 21:50:18 -0000 Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com) (209.85.216.171) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 31 Jul 2012 21:50:18 -0000 Received: by qcad1 with SMTP id d1so4062130qca.30 for ; Tue, 31 Jul 2012 14:50:17 -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=9zZplSDoVMDRUprRXY3N70jXN8V9e7X1BkED/9tC4+k=; b=nINIWhIprh5KHiR9OI7APZFthO1qYa6lmRV8a0EQFTTEWbYVWmQletWvOujOO/mMws +PuawUS40/cFrLWXo90tYOPSDkXJIwikwey7TjmfQJhoXeEY0cK9E6n6+PdcN9rHQire VjEoCz4uMcoFsPxq8yzcshZuBHX82XJVqNKYCMOnt0n0WO2iwMdOrvJL5TvHaEZwQR/q WsAJnd++9uqr6u3vcIcV8v1AeX6Q8Jas9K8TVJNU2mVKm8XQSyfGnvrKwrf4a7y26a7v tpP5M+if/5+B/qhv8A6++2oc0XZ04dh6i7tJOW74XaNLTxEpFCqgKlStdi8KOrL//TWz 1AUg== MIME-Version: 1.0 Received: by 10.224.32.205 with SMTP id e13mr32198691qad.69.1343771417404; Tue, 31 Jul 2012 14:50:17 -0700 (PDT) Received: by 10.229.56.97 with HTTP; Tue, 31 Jul 2012 14:50:17 -0700 (PDT) In-Reply-To: <1332842573.2485.88.camel@leeds.uk.xensource.com> References: <1332838109433-5597283.post@n5.nabble.com> <1332840330.2485.70.camel@leeds.uk.xensource.com> <1332841414026-5597400.post@n5.nabble.com> <1332842573.2485.88.camel@leeds.uk.xensource.com> Date: Tue, 31 Jul 2012 14:50:17 -0700 Message-ID: From: Anirban Chakraborty To: Wei Liu X-Mailman-Approved-At: Wed, 01 Aug 2012 04:30:59 +0000 Cc: Kristoffer Harthing Egefelt , "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 Do not worry about failed card response code. It indicates that the driver was not able to get the FW dump template during initialization as that CDRP command is not supported by the onboard FW. In order to get line rate, it is important that you run the driver with all the msi-x vectors. Looks like the driver could get only legacy interrupt in this case. -Anirban On Tue, Mar 27, 2012 at 3:02 AM, Wei Liu wrote: > On Tue, 2012-03-27 at 10:43 +0100, Kristoffer Harthing Egefelt wrote: >> Please find dmesg below - do you see any hints? >> The onboard 1gig network cards are in fabric A, the 10gig's are in fabric B. >> I have disabled the onboard NICs so the 10gigs is eth0 and eth1. >> I have tried enabling the onboard NICs, making the 10gig's eth2 and eth3 >> without luck. >> >> Thanks >> >> oot@node0301:/var/log# cat dmesg.0 > > > >> [ 12.646309] input: PC Speaker as /devices/platform/pcspkr/input/input1 >> [ 12.696167] QLogic 1/10 GbE Converged/Intelligent Ethernet Driver v5.0.25 >> [ 12.696278] xen: registering gsi 38 triggering 0 polarity 1 >> [ 12.696304] xen: --> pirq=38 -> irq=38 (gsi=38) >> [ 12.696340] qlcnic 0000:03:00.0: PCI INT A -> GSI 38 (level, low) -> IRQ >> 38 > > This one. > >> [ 12.696355] qlcnic 0000:03:00.0: setting latency timer to 64 >> [ 12.697214] qlcnic 0000:03:00.0: 2MB memory map > > > >> [ 13.077174] ata1: SATA link down (SStatus 0 SControl 300) >> [ 13.077266] ata2: SATA link down (SStatus 0 SControl 300) >> [ 13.221115] usb 2-3: new high-speed USB device number 3 using ehci_hcd >> [ 13.345114] qlcnic 0000:03:00.0: phy port: 0 switch_mode: 0, >> [ 13.345116] max_tx_q: 1 max_rx_q: 8 min_tx_bw: 0x0, >> [ 13.345117] max_tx_bw: 0x64 max_mtu:0x2580, capabilities: 0x6affae >> [ 13.361103] qlcnic 0000:03:00.0: failed card response code:0x10 >> [ 13.361162] qlcnic 0000:03:00.0: Can't get template size 16 >> [ 13.361167] qlcnic 0000:03:00.0: firmware v4.7.83 > > Failed. :-( > >> [ 13.371640] usb 2-3: New USB device found, idVendor=046b, idProduct=ff90 >> [ 13.371646] usb 2-3: New USB device strings: Mfr=1, Product=2, >> SerialNumber=3 >> [ 13.371650] usb 2-3: Product: Composite Device >> [ 13.371653] usb 2-3: Manufacturer: American Megatrends Inc. >> [ 13.371657] usb 2-3: SerialNumber: serial >> [ 13.393138] qlcnic: 24:b6:fd:64:1e:45: QME8242-k 10GbE Dual Port >> Mezzanine Card Board Chip rev 0x54 >> [ 13.393460] usbcore: registered new interface driver uas >> [ 13.393559] qlcnic 0000:03:00.0: using msi-x interrupts >> [ 13.394251] qlcnic 0000:03:00.0: eth0: XGbE port initialized > > And this one. > >> [ 13.394290] xen: registering gsi 38 triggering 0 polarity 1 >> [ 13.394304] xen_map_pirq_gsi: returning irq 38 for gsi 38 >> [ 13.394308] xen: --> pirq=38 -> irq=38 (gsi=38) >> [ 13.394311] Already setup the GSI :38 >> [ 13.394316] qlcnic 0000:03:00.1: PCI INT A -> GSI 38 (level, low) -> IRQ >> 38 >> [ 13.394331] qlcnic 0000:03:00.1: setting latency timer to 64 >> [ 13.395317] qlcnic 0000:03:00.1: 2MB memory map >> [ 13.404052] Initializing USB Mass Storage driver... >> [ 13.404264] scsi3 : usb-storage 2-3:1.0 >> [ 13.404487] scsi4 : usb-storage 2-3:1.1 >> [ 13.404693] scsi5 : usb-storage 2-3:1.2 >> [ 13.404799] usbcore: registered new interface driver usb-storage >> [ 13.404802] USB Mass Storage support registered. >> [ 13.409136] qlcnic 0000:03:00.1: phy port: 1 switch_mode: 0, >> [ 13.409138] max_tx_q: 1 max_rx_q: 8 min_tx_bw: 0x0, >> [ 13.409139] max_tx_bw: 0x64 max_mtu:0x2580, capabilities: 0x6affae >> [ 13.425118] qlcnic 0000:03:00.1: failed card response code:0x10 >> [ 13.425174] qlcnic 0000:03:00.1: Can't get template size 16 >> [ 13.425178] qlcnic 0000:03:00.1: firmware v4.7.83 >> [ 13.449525] qlcnic 0000:03:00.1: using msi-x interrupts >> [ 13.450132] qlcnic 0000:03:00.1: eth1: XGbE port initialized > > And this one. > >> [ 13.677120] usb 5-2: new full-speed USB device number 2 using uhci_hcd >> [ 13.840290] usb 5-2: New USB device found, idVendor=046b, idProduct=ff10 >> [ 13.840296] usb 5-2: New USB device strings: Mfr=1, Product=2, >> SerialNumber=3 > > > >> [ 18.325633] ip_tables: (C) 2000-2006 Netfilter Core Team >> [ 18.434036] device xenbr0 entered promiscuous mode >> [ 18.445825] device eth1 entered promiscuous mode >> [ 18.446092] device eth0 entered promiscuous mode > > I have no idea about the "failed card response", but there are eth0 and > eth1 presented. :-) > > And it looks like that they are both bridged to xenbr0 by userspace > tools? > > > Wei. > > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 04:31:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 04: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 1SwQaJ-0002t9-HX; Wed, 01 Aug 2012 04:30:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwKKd-0002pf-3q for xen-devel@lists.xensource.com; Tue, 31 Jul 2012 21:50:23 +0000 Received: from [85.158.143.35:7474] by server-2.bemta-4.messagelabs.com id 65/A0-17938-D1358105; Tue, 31 Jul 2012 21:50:21 +0000 X-Env-Sender: anirbanchak@gmail.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1343771417!16207705!1 X-Originating-IP: [209.85.216.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14738 invoked from network); 31 Jul 2012 21:50:18 -0000 Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com) (209.85.216.171) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 31 Jul 2012 21:50:18 -0000 Received: by qcad1 with SMTP id d1so4062130qca.30 for ; Tue, 31 Jul 2012 14:50:17 -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=9zZplSDoVMDRUprRXY3N70jXN8V9e7X1BkED/9tC4+k=; b=nINIWhIprh5KHiR9OI7APZFthO1qYa6lmRV8a0EQFTTEWbYVWmQletWvOujOO/mMws +PuawUS40/cFrLWXo90tYOPSDkXJIwikwey7TjmfQJhoXeEY0cK9E6n6+PdcN9rHQire VjEoCz4uMcoFsPxq8yzcshZuBHX82XJVqNKYCMOnt0n0WO2iwMdOrvJL5TvHaEZwQR/q WsAJnd++9uqr6u3vcIcV8v1AeX6Q8Jas9K8TVJNU2mVKm8XQSyfGnvrKwrf4a7y26a7v tpP5M+if/5+B/qhv8A6++2oc0XZ04dh6i7tJOW74XaNLTxEpFCqgKlStdi8KOrL//TWz 1AUg== MIME-Version: 1.0 Received: by 10.224.32.205 with SMTP id e13mr32198691qad.69.1343771417404; Tue, 31 Jul 2012 14:50:17 -0700 (PDT) Received: by 10.229.56.97 with HTTP; Tue, 31 Jul 2012 14:50:17 -0700 (PDT) In-Reply-To: <1332842573.2485.88.camel@leeds.uk.xensource.com> References: <1332838109433-5597283.post@n5.nabble.com> <1332840330.2485.70.camel@leeds.uk.xensource.com> <1332841414026-5597400.post@n5.nabble.com> <1332842573.2485.88.camel@leeds.uk.xensource.com> Date: Tue, 31 Jul 2012 14:50:17 -0700 Message-ID: From: Anirban Chakraborty To: Wei Liu X-Mailman-Approved-At: Wed, 01 Aug 2012 04:30:59 +0000 Cc: Kristoffer Harthing Egefelt , "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 Do not worry about failed card response code. It indicates that the driver was not able to get the FW dump template during initialization as that CDRP command is not supported by the onboard FW. In order to get line rate, it is important that you run the driver with all the msi-x vectors. Looks like the driver could get only legacy interrupt in this case. -Anirban On Tue, Mar 27, 2012 at 3:02 AM, Wei Liu wrote: > On Tue, 2012-03-27 at 10:43 +0100, Kristoffer Harthing Egefelt wrote: >> Please find dmesg below - do you see any hints? >> The onboard 1gig network cards are in fabric A, the 10gig's are in fabric B. >> I have disabled the onboard NICs so the 10gigs is eth0 and eth1. >> I have tried enabling the onboard NICs, making the 10gig's eth2 and eth3 >> without luck. >> >> Thanks >> >> oot@node0301:/var/log# cat dmesg.0 > > > >> [ 12.646309] input: PC Speaker as /devices/platform/pcspkr/input/input1 >> [ 12.696167] QLogic 1/10 GbE Converged/Intelligent Ethernet Driver v5.0.25 >> [ 12.696278] xen: registering gsi 38 triggering 0 polarity 1 >> [ 12.696304] xen: --> pirq=38 -> irq=38 (gsi=38) >> [ 12.696340] qlcnic 0000:03:00.0: PCI INT A -> GSI 38 (level, low) -> IRQ >> 38 > > This one. > >> [ 12.696355] qlcnic 0000:03:00.0: setting latency timer to 64 >> [ 12.697214] qlcnic 0000:03:00.0: 2MB memory map > > > >> [ 13.077174] ata1: SATA link down (SStatus 0 SControl 300) >> [ 13.077266] ata2: SATA link down (SStatus 0 SControl 300) >> [ 13.221115] usb 2-3: new high-speed USB device number 3 using ehci_hcd >> [ 13.345114] qlcnic 0000:03:00.0: phy port: 0 switch_mode: 0, >> [ 13.345116] max_tx_q: 1 max_rx_q: 8 min_tx_bw: 0x0, >> [ 13.345117] max_tx_bw: 0x64 max_mtu:0x2580, capabilities: 0x6affae >> [ 13.361103] qlcnic 0000:03:00.0: failed card response code:0x10 >> [ 13.361162] qlcnic 0000:03:00.0: Can't get template size 16 >> [ 13.361167] qlcnic 0000:03:00.0: firmware v4.7.83 > > Failed. :-( > >> [ 13.371640] usb 2-3: New USB device found, idVendor=046b, idProduct=ff90 >> [ 13.371646] usb 2-3: New USB device strings: Mfr=1, Product=2, >> SerialNumber=3 >> [ 13.371650] usb 2-3: Product: Composite Device >> [ 13.371653] usb 2-3: Manufacturer: American Megatrends Inc. >> [ 13.371657] usb 2-3: SerialNumber: serial >> [ 13.393138] qlcnic: 24:b6:fd:64:1e:45: QME8242-k 10GbE Dual Port >> Mezzanine Card Board Chip rev 0x54 >> [ 13.393460] usbcore: registered new interface driver uas >> [ 13.393559] qlcnic 0000:03:00.0: using msi-x interrupts >> [ 13.394251] qlcnic 0000:03:00.0: eth0: XGbE port initialized > > And this one. > >> [ 13.394290] xen: registering gsi 38 triggering 0 polarity 1 >> [ 13.394304] xen_map_pirq_gsi: returning irq 38 for gsi 38 >> [ 13.394308] xen: --> pirq=38 -> irq=38 (gsi=38) >> [ 13.394311] Already setup the GSI :38 >> [ 13.394316] qlcnic 0000:03:00.1: PCI INT A -> GSI 38 (level, low) -> IRQ >> 38 >> [ 13.394331] qlcnic 0000:03:00.1: setting latency timer to 64 >> [ 13.395317] qlcnic 0000:03:00.1: 2MB memory map >> [ 13.404052] Initializing USB Mass Storage driver... >> [ 13.404264] scsi3 : usb-storage 2-3:1.0 >> [ 13.404487] scsi4 : usb-storage 2-3:1.1 >> [ 13.404693] scsi5 : usb-storage 2-3:1.2 >> [ 13.404799] usbcore: registered new interface driver usb-storage >> [ 13.404802] USB Mass Storage support registered. >> [ 13.409136] qlcnic 0000:03:00.1: phy port: 1 switch_mode: 0, >> [ 13.409138] max_tx_q: 1 max_rx_q: 8 min_tx_bw: 0x0, >> [ 13.409139] max_tx_bw: 0x64 max_mtu:0x2580, capabilities: 0x6affae >> [ 13.425118] qlcnic 0000:03:00.1: failed card response code:0x10 >> [ 13.425174] qlcnic 0000:03:00.1: Can't get template size 16 >> [ 13.425178] qlcnic 0000:03:00.1: firmware v4.7.83 >> [ 13.449525] qlcnic 0000:03:00.1: using msi-x interrupts >> [ 13.450132] qlcnic 0000:03:00.1: eth1: XGbE port initialized > > And this one. > >> [ 13.677120] usb 5-2: new full-speed USB device number 2 using uhci_hcd >> [ 13.840290] usb 5-2: New USB device found, idVendor=046b, idProduct=ff10 >> [ 13.840296] usb 5-2: New USB device strings: Mfr=1, Product=2, >> SerialNumber=3 > > > >> [ 18.325633] ip_tables: (C) 2000-2006 Netfilter Core Team >> [ 18.434036] device xenbr0 entered promiscuous mode >> [ 18.445825] device eth1 entered promiscuous mode >> [ 18.446092] device eth0 entered promiscuous mode > > I have no idea about the "failed card response", but there are eth0 and > eth1 presented. :-) > > And it looks like that they are both bridged to xenbr0 by userspace > tools? > > > Wei. > > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 05:27:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 05:27:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwRRn-0004Ge-9u; Wed, 01 Aug 2012 05:26:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwRRl-0004GY-SN for xen-devel@lists.xensource.com; Wed, 01 Aug 2012 05:26:14 +0000 Received: from [85.158.138.51:39221] by server-1.bemta-3.messagelabs.com id 8F/AE-31934-4FDB8105; Wed, 01 Aug 2012 05:26:12 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1343798772!29855466!1 X-Originating-IP: [209.85.212.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2583 invoked from network); 1 Aug 2012 05:26:12 -0000 Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com) (209.85.212.171) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Aug 2012 05:26:12 -0000 Received: by wibhq4 with SMTP id hq4so3151845wib.6 for ; Tue, 31 Jul 2012 22:26:12 -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=w9FlkgwPoVSkUBV5OUAQzEQ4ts+BvEOpsjL54NaK3uI=; b=oc4JwXXBU0mQleAMAMquP5+j9vFcxeBVUZaXgul6M/cdN/VOCcPgH5D7tWK5NOpP6B gnls77GPQEFXkHBwew9UASoWrSyOXCEpjP/Lw/pdYbtIREmyuWrqSejkBy2cDAT9d7Dl beY6KTvRRWhq26ZsoC0ff0eEcJm3a3ynZ76SbmFd/C+vIeQ7QyTVsSyukNv2jZDsEm8B +lizRo+qmO2UDUYW+ce25JweGm85kdJEMrNzchESQ0Oso5RLeh5ybkY+27Gw8I+46PM8 6C4JzwzwS6DL0YGLSog5A2KZuDUhV5eTUYMF3Oabtqoa6bV8fD1MHSPZRbo9eogkwlhg i7RQ== Received: by 10.180.83.106 with SMTP id p10mr8743847wiy.21.1343798772042; Tue, 31 Jul 2012 22:26:12 -0700 (PDT) Received: from [192.168.1.68] (host86-178-46-238.range86-178.btcentralplus.com. [86.178.46.238]) by mx.google.com with ESMTPS id o2sm5913874wiz.11.2012.07.31.22.26.10 (version=SSLv3 cipher=OTHER); Tue, 31 Jul 2012 22:26:11 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 01 Aug 2012 06:26:09 +0100 From: Keir Fraser To: Shakeel Butt , Daniel De Graaf Message-ID: Thread-Topic: [Xen-devel] XSM instead of IS_PRIV Thread-Index: Ac1vpigA6j7XhULvN0iZLp+YldCAMQ== In-Reply-To: Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] XSM instead of IS_PRIV X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/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/08/2012 03:51, "Shakeel Butt" wrote: >> Once this is done, it will make sense to change the XSM header file so >> that the appropriate xsm_* hooks resolve to IS_PRIV when XSM is not >> enabled. This would allow the IS_PRIV hooks covered by XSM to be >> completely removed, assuming the Xen developers agree that the XSM hooks >> cover all all the important code. > > Thanks for replying. So, is there consensus among the Xen community > to adopt this patch (xsm hooks replacing IS_PRIV) on upstream Xen? Assuming it can be done cleanly and comprehensively, with same behaviour as IS_PRIV for an out-of-the-box setup, yes. What's not to like about that? :) -- Keir > thanks, > Shakeel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/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 Aug 01 05:27:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 05:27:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwRRn-0004Ge-9u; Wed, 01 Aug 2012 05:26:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwRRl-0004GY-SN for xen-devel@lists.xensource.com; Wed, 01 Aug 2012 05:26:14 +0000 Received: from [85.158.138.51:39221] by server-1.bemta-3.messagelabs.com id 8F/AE-31934-4FDB8105; Wed, 01 Aug 2012 05:26:12 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1343798772!29855466!1 X-Originating-IP: [209.85.212.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2583 invoked from network); 1 Aug 2012 05:26:12 -0000 Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com) (209.85.212.171) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Aug 2012 05:26:12 -0000 Received: by wibhq4 with SMTP id hq4so3151845wib.6 for ; Tue, 31 Jul 2012 22:26:12 -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=w9FlkgwPoVSkUBV5OUAQzEQ4ts+BvEOpsjL54NaK3uI=; b=oc4JwXXBU0mQleAMAMquP5+j9vFcxeBVUZaXgul6M/cdN/VOCcPgH5D7tWK5NOpP6B gnls77GPQEFXkHBwew9UASoWrSyOXCEpjP/Lw/pdYbtIREmyuWrqSejkBy2cDAT9d7Dl beY6KTvRRWhq26ZsoC0ff0eEcJm3a3ynZ76SbmFd/C+vIeQ7QyTVsSyukNv2jZDsEm8B +lizRo+qmO2UDUYW+ce25JweGm85kdJEMrNzchESQ0Oso5RLeh5ybkY+27Gw8I+46PM8 6C4JzwzwS6DL0YGLSog5A2KZuDUhV5eTUYMF3Oabtqoa6bV8fD1MHSPZRbo9eogkwlhg i7RQ== Received: by 10.180.83.106 with SMTP id p10mr8743847wiy.21.1343798772042; Tue, 31 Jul 2012 22:26:12 -0700 (PDT) Received: from [192.168.1.68] (host86-178-46-238.range86-178.btcentralplus.com. [86.178.46.238]) by mx.google.com with ESMTPS id o2sm5913874wiz.11.2012.07.31.22.26.10 (version=SSLv3 cipher=OTHER); Tue, 31 Jul 2012 22:26:11 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 01 Aug 2012 06:26:09 +0100 From: Keir Fraser To: Shakeel Butt , Daniel De Graaf Message-ID: Thread-Topic: [Xen-devel] XSM instead of IS_PRIV Thread-Index: Ac1vpigA6j7XhULvN0iZLp+YldCAMQ== In-Reply-To: Mime-version: 1.0 Cc: xen-devel Subject: Re: [Xen-devel] XSM instead of IS_PRIV X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/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/08/2012 03:51, "Shakeel Butt" wrote: >> Once this is done, it will make sense to change the XSM header file so >> that the appropriate xsm_* hooks resolve to IS_PRIV when XSM is not >> enabled. This would allow the IS_PRIV hooks covered by XSM to be >> completely removed, assuming the Xen developers agree that the XSM hooks >> cover all all the important code. > > Thanks for replying. So, is there consensus among the Xen community > to adopt this patch (xsm hooks replacing IS_PRIV) on upstream Xen? Assuming it can be done cleanly and comprehensively, with same behaviour as IS_PRIV for an out-of-the-box setup, yes. What's not to like about that? :) -- Keir > thanks, > Shakeel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/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 Aug 01 05:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 05: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 1SwRwL-0004ZT-Va; Wed, 01 Aug 2012 05:57:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwRwJ-0004ZI-Ji for xen-devel@lists.xen.org; Wed, 01 Aug 2012 05:57:48 +0000 Received: from [85.158.143.35:57619] by server-2.bemta-4.messagelabs.com id 24/27-17938-A55C8105; Wed, 01 Aug 2012 05:57:46 +0000 X-Env-Sender: hufan@websense.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1343800665!16247174!1 X-Originating-IP: [208.87.234.190] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA4Ljg3LjIzNC4xOTAgPT4gMTY4NDUxNw==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4308 invoked from network); 1 Aug 2012 05:57:45 -0000 Received: from cluster-h.mailcontrol.com (HELO cluster-h.mailcontrol.com) (208.87.234.190) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Aug 2012 05:57:45 -0000 Received: from rly29h.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly29h.srv.mailcontrol.com (MailControl) with ESMTP id q715vd1o002408; Wed, 1 Aug 2012 06:57:42 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rly29h.srv.mailcontrol.com (MailControl) id q715vT5F001307; Wed, 1 Aug 2012 06:57:29 +0100 Received: from SSDEXCH1A.websense.com ([204.15.64.107]) by rly29h-eth0.srv.mailcontrol.com (envelope-sender ) (MIMEDefang) with ESMTP id q715vOMG000567 (TLS bits=128 verify=FAIL); Wed, 01 Aug 2012 06:57:29 +0100 (BST) Received: from SBJEXCH2B.websense.com (10.32.8.112) by SSDEXCH1A.websense.com (10.8.1.91) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 31 Jul 2012 22:57:18 -0700 Received: from SBJEXCH1A.websense.com ([169.254.1.209]) by SBJEXCH2B.websense.com ([::1]) with mapi id 14.02.0283.003; Wed, 1 Aug 2012 13:57:14 +0800 From: "Fan, Huaxiang" To: "xen-users@lists.xen.org" Thread-Topic: PCI passthrough for domU allocated with more than 4G memory Thread-Index: Ac1vp0xm5UJayF9xRx2DE9F/z2HnhA== Date: Wed, 1 Aug 2012 05:57:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.134.111] MIME-Version: 1.0 X-Scanned-By: MailControl 8316.0 (www.mailcontrol.com) on 10.72.1.139 Cc: "Konrad Rzeszutek Wilk \(konrad.wilk@oracle.com\)" , "xen-devel@lists.xen.org" Subject: [Xen-devel] PCI passthrough for domU allocated with more than 4G memory X-BeenThere: xen-devel@lists.xen.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="===============6773783635368204994==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6773783635368204994== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E71FC5D6F96C3C4B93FC8FF942D924C675ADD043SBJEXCH1Awebsen_" --_000_E71FC5D6F96C3C4B93FC8FF942D924C675ADD043SBJEXCH1Awebsen_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have encountered some strange problems when I was trying to PCI passthrou= gh Broadcom 5709/5716 NICs to domUs allocated with more than 4G memory. Ple= ase see below for details. My environment is: Hardware Platform: DELL R210 with 2 Broadcom 5709 NICs and 2 Broadcom 5716 = NICs Xen: xen 4.2 unstable (64bits for hypervisor and 32bit for tools) Kernel for both dom0 and domUs: xenified kernel 2.6.32.57 (32bit) OS: CentOS 6.2 (32bit) The general info regarding to xen can be get via below command # xl info host : 7.8 release : 2.6.32.57 version : #1 SMP Fri Jul 6 18:44:16 CST 2012 machine : i686 nr_cpus : 8 max_cpu_id : 31 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 2 cpu_mhz : 2660 hw_caps : bfebfbff:28100800:00000000:00003b40:0098e3fd:00000= 000:00000001:00000000 virt_caps : hvm hvm_directio total_memory : 8182 free_memory : 7046 sharing_freed_memory : 0 sharing_used_memory : 0 free_cpus : 0 xen_major : 4 xen_minor : 2 xen_extra : -unstable xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-= 3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=3D0xff400000 xen_changeset : unavailable xen_commandline : dom0_mem=3D1024M dom0_max_vcpus=3D2 dom0_vcpus_pin cc_compiler : gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) cc_compile_by : root cc_compile_domain : cc_compile_date : Thu Jul 12 11:20:56 CST 2012 xend_config_format : 4 case 1> I specified PV-domU config as below memory=3D3072 maxmem=3D6144 name=3D"bs" vif=3D['ip=3D169.254.254.1,script=3Dvif-nat',] disk=3D['file:/root/bs.img,xvda1,w'] kernel=3D'/root/vmlinuz' extra=3D"iommu=3Dsoft console=3Dhvc0" ramdisk=3D'/root/initrd.img' root=3D"/dev/xvda1 ro" pci=3D['01:00.0','01:00.1'] and then start domU. After that I executed below command # xl list Name ID Mem VCPUs State Tim= e(s) Domain-0 0 1024 2 r----- = 88.7 bs 2 3072 1 -b---- = 1.1 It seemed normal to me. But when I logon bs domU, and executed below command # cat /proc/meminfo | head MemTotal: 6158940 kB MemFree: 2944776 kB Buffers: 5108 kB Cached: 32292 kB SwapCached: 0 kB Active: 21456 kB Inactive: 22936 kB Active(anon): 7000 kB Inactive(anon): 108 kB Active(file): 14456 kB It indicated the total memory was 6G, why? When I back to dom0, I executed below command # xl mem-set bs 6144 # xl list Name ID Mem VCPUs State Tim= e(s) Domain-0 0 1024 2 r----- = 93.5 bs 2 6144 1 -b---- = 10.5 It seemed normal to me. But when I logon bs domU again and executed below c= ommand # cat /proc/meminfo | head MemTotal: 9304668 kB MemFree: 6087540 kB Buffers: 5168 kB Cached: 32464 kB SwapCached: 0 kB Active: 22300 kB Inactive: 22408 kB Active(anon): 7080 kB Inactive(anon): 108 kB Active(file): 15220 kB It indicated total memory was 9G (6G + 3G). It was wired. Any idea about th= is? Case 2> I specified PV-domU config as below memory=3D6144 maxmem=3D6144 name=3D"bs" vif=3D['ip=3D169.254.254.1,script=3Dvif-nat',] disk=3D['file:/root/bs.img,xvda1,w'] kernel=3D'/root/vmlinuz' extra=3D"iommu=3Dsoft console=3Dhvc0" ramdisk=3D'/root/initrd.img' root=3D"/dev/xvda1 ro" pci=3D['01:00.0','01:00.1'] and then start domU. After that I executed below command # xl list Name ID Mem VCPUs State Tim= e(s) Domain-0 0 648 2 r----- 1= 20.5 bs 3 3360 1 -b---- = 7.0 the output was very confusing. Why dom0 memory had been shrank to 648M and = only 3360M assigned to bs domU? My own analysis: I extracted the bios e820 memory map on bs domU as below [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 00000000000a0000 (usable) [ 0.000000] Xen: 00000000000a0000 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 00000000bf699000 (usable) [ 0.000000] Xen: 00000000bf699000 - 00000000bf6af000 (reserved) [ 0.000000] Xen: 00000000bf6af000 - 00000000bf6ce000 (ACPI data) [ 0.000000] Xen: 00000000bf6ce000 - 00000000c0000000 (reserved) [ 0.000000] Xen: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] Xen: 00000000fe000000 - 0000000100000000 (reserved) [ 0.000000] Xen: 0000000180000000 - 00000001c33ec000 (usable) I think the root cause might be related to the holes between c0000000 and e= 0000000 and between f0000000 and fe000000 and between 100000000 and 1800000= 00. And I think the e820_host option set according to my tracking. Thanks in advance HUAXIANG FAN Software Engineer II WEBSENSE NETWORK SECURITY TECHNOLOGY R&D (BEIJING) CO. LTD. ph: +8610.5884.4327 fax: +8610.5884.4727 www.websense.cn Websense TRITON(tm) For Essential Information Protection(tm) Web Security | Data Security | Email Security Protected by Websense Hosted Email Security -- www.websense.com=20 --_000_E71FC5D6F96C3C4B93FC8FF942D924C675ADD043SBJEXCH1Awebsen_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have encountered some strange problems when I was = trying to PCI passthrough Broadcom 5709/5716 NICs to domUs allocated with m= ore than 4G memory. Please see below for details.

 

My environment is:

Hardware Platform: DELL R210 with 2 Broadcom 5709 NI= Cs and 2 Broadcom 5716 NICs

Xen: xen 4.2 unstable (64bits for hypervisor and 32b= it for tools)

Kernel for both dom0 and domUs: xenified kernel 2.6.= 32.57 (32bit)

OS: CentOS 6.2 (32bit)

 

The general info regarding to xen can be get via bel= ow command

# xl info

host       &nb= sp;           : 7.8<= /o:p>

release       =          : 2.6.32.57

version       =          : #1 SMP Fri Jul 6 18:44:1= 6 CST 2012

machine       =          : i686

nr_cpus       =          : 8

max_cpu_id      &nb= sp;      : 31

nr_nodes       = ;        : 1

cores_per_socket     &nb= sp; : 4

threads_per_core     &nb= sp; : 2

cpu_mhz       =          : 2660

hw_caps       =          : bfebfbff:28100800:000000= 00:00003b40:0098e3fd:00000000:00000001:00000000

virt_caps      &nbs= p;       : hvm hvm_directio

total_memory      &= nbsp;    : 8182

free_memory      &n= bsp;     : 7046

sharing_freed_memory   : 0

sharing_used_memory    : 0

free_cpus      &nbs= p;       : 0

xen_major      &nbs= p;       : 4

xen_minor      &nbs= p;       : 2

xen_extra      &nbs= p;       : -unstable

xen_caps       = ;        : xen-3.0-x86_64 xen-3.0-x86_32= p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64

xen_scheduler      =     : credit

xen_pagesize      &= nbsp;    : 4096

platform_params     &nbs= p;  : virt_start=3D0xff400000

xen_changeset      =     : unavailable

xen_commandline     &nbs= p;  : dom0_mem=3D1024M dom0_max_vcpus=3D2 dom0_vcpus_pin

cc_compiler      &n= bsp;     : gcc version 4.4.6 20110731 (Red Hat 4.4.6-3)= (GCC)

cc_compile_by      =     : root

cc_compile_domain      :=

cc_compile_date     &nbs= p;  : Thu Jul 12 11:20:56 CST 2012

xend_config_format     : 4

 

case 1> I specified PV-domU config as below<= /o:p>

memory=3D3072

maxmem=3D6144

name=3D"bs"

vif=3D['ip=3D169.254.254.1,script=3Dvif-nat',]

disk=3D['file:/root/bs.img,xvda1,w']

kernel=3D'/root/vmlinuz'

extra=3D"iommu=3Dsoft console=3Dhvc0"

ramdisk=3D'/root/initrd.img'

root=3D"/dev/xvda1 ro"

pci=3D['01:00.0','01:00.1']

 

and then start domU. After that I executed below com= mand

# xl list

Name       &nb= sp;            =             &nb= sp;       ID   Mem VCPUs  = ;    State   Time(s)

Domain-0       = ;            &n= bsp;            = ;     0  1024     2  = ;   r-----      88.7

bs        = ;            &n= bsp;            &nbs= p;         2  3072 &= nbsp;   1     -b----    &= nbsp;  1.1

 

It seemed normal to me. But when I logon bs domU, an= d executed below command

# cat /proc/meminfo | head

MemTotal:      &nbs= p; 6158940 kB

MemFree:       = ;  2944776 kB

Buffers:       = ;     5108 kB

Cached:       =      32292 kB

SwapCached:      &n= bsp;     0 kB

Active:       =      21456 kB

Inactive:      &nbs= p;   22936 kB

Active(anon):      = 7000 kB

Inactive(anon):      108= kB

Active(file):      14456= kB

 

It indicated the total memory was 6G, why?

When I back to dom0, I executed below command

# xl mem-set bs 6144

# xl list

Name       &nb= sp;            =             &nb= sp;       ID   Mem VCPUs  = ;    State   Time(s)

Domain-0       = ;            &n= bsp;            = ;     0  1024     2  = ;   r-----      93.5

bs        = ;            &n= bsp;            = ;          2  6144 &= nbsp;   1     -b----    &= nbsp; 10.5

It seemed normal to me. But when I logon bs domU aga= in and executed below command

# cat /proc/meminfo | head

MemTotal:      &nbs= p; 9304668 kB

MemFree:       = ;  6087540 kB

Buffers:       = ;     5168 kB

Cached:       =      32464 kB

SwapCached:      &n= bsp;     0 kB

Active:       =      22300 kB

Inactive:      &nbs= p;   22408 kB

Active(anon):      = 7080 kB

Inactive(anon):      108= kB

Active(file):      15220= kB

 

It indicated total memory was 9G (6G + 3G). I= t was wired. Any idea about this?

Case 2> I specified PV-domU config as below<= /o:p>

memory=3D6144

maxmem=3D6144

name=3D"bs"

vif=3D['ip=3D169.254.254.1,script=3Dvif-nat',]

disk=3D['file:/root/bs.img,xvda1,w']

kernel=3D'/root/vmlinuz'

extra=3D"iommu=3Dsoft console=3Dhvc0"

ramdisk=3D'/root/initrd.img'

root=3D"/dev/xvda1 ro"

pci=3D['01:00.0','01:00.1']

 

and then start domU. After that I executed below com= mand

# xl list

Name       &nb= sp;            =             &nb= sp;       ID   Mem VCPUs  = ;    State   Time(s)

Domain-0       = ;            &n= bsp;            = ;     0   648     2 =     r-----     120.5

bs        = ;            &n= bsp;            = ;          3  3360 &= nbsp;   1     -b----    &= nbsp;  7.0

 

the output was very confusing. Why dom0 memory had b= een shrank to 648M and only 3360M assigned to bs domU?

 

My own analysis:

I extracted the bios e820 memory map on bs domU as b= elow

[    0.000000] BIOS-provided physi= cal RAM map:

[    0.000000]  Xen: 00000000= 00000000 - 00000000000a0000 (usable)

[    0.000000]  Xen: 00000000= 000a0000 - 0000000000100000 (reserved)

[    0.000000]  Xen: 00000000= 00100000 - 00000000bf699000 (usable)

[    0.000000]  Xen: 00000000= bf699000 - 00000000bf6af000 (reserved)

[    0.000000]  Xen: 00000000= bf6af000 - 00000000bf6ce000 (ACPI data)

[    0.000000]  Xen: 00000000= bf6ce000 - 00000000c0000000 (reserved)

[    0.000000]  Xen: 00000000= e0000000 - 00000000f0000000 (reserved)

[    0.000000]  Xen: 00000000= fe000000 - 0000000100000000 (reserved)

[    0.000000]  Xen: 00000001= 80000000 - 00000001c33ec000 (usable)

 

I think the root cause might be related to the holes= between c0000000 and e0000000 and between f0000000 and fe000000 and betwee= n 100000000 and 180000000. And I think the e820_host option set according t= o my tracking.

 

Thanks in advance

HUAXIANG FAN
Software Engineer II

WEBSENSE NETWORK SECURITY TECHNOLOGY R&am= p;D (BEIJING) CO. LTD.
ph: +8610.5884.4327
fax: +8610.5884.4727
www.websense.cn

Websense TRITON™
For Essential Information Protection™
Web Security | = Data Security= | Email Security



Protected by Websense Hosted Email Security = 212; www.websense.com

--_000_E71FC5D6F96C3C4B93FC8FF942D924C675ADD043SBJEXCH1Awebsen_-- --===============6773783635368204994== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6773783635368204994==-- From xen-devel-bounces@lists.xen.org Wed Aug 01 05:58:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 05: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 1SwRwL-0004ZT-Va; Wed, 01 Aug 2012 05:57:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwRwJ-0004ZI-Ji for xen-devel@lists.xen.org; Wed, 01 Aug 2012 05:57:48 +0000 Received: from [85.158.143.35:57619] by server-2.bemta-4.messagelabs.com id 24/27-17938-A55C8105; Wed, 01 Aug 2012 05:57:46 +0000 X-Env-Sender: hufan@websense.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1343800665!16247174!1 X-Originating-IP: [208.87.234.190] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA4Ljg3LjIzNC4xOTAgPT4gMTY4NDUxNw==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4308 invoked from network); 1 Aug 2012 05:57:45 -0000 Received: from cluster-h.mailcontrol.com (HELO cluster-h.mailcontrol.com) (208.87.234.190) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Aug 2012 05:57:45 -0000 Received: from rly29h.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly29h.srv.mailcontrol.com (MailControl) with ESMTP id q715vd1o002408; Wed, 1 Aug 2012 06:57:42 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rly29h.srv.mailcontrol.com (MailControl) id q715vT5F001307; Wed, 1 Aug 2012 06:57:29 +0100 Received: from SSDEXCH1A.websense.com ([204.15.64.107]) by rly29h-eth0.srv.mailcontrol.com (envelope-sender ) (MIMEDefang) with ESMTP id q715vOMG000567 (TLS bits=128 verify=FAIL); Wed, 01 Aug 2012 06:57:29 +0100 (BST) Received: from SBJEXCH2B.websense.com (10.32.8.112) by SSDEXCH1A.websense.com (10.8.1.91) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 31 Jul 2012 22:57:18 -0700 Received: from SBJEXCH1A.websense.com ([169.254.1.209]) by SBJEXCH2B.websense.com ([::1]) with mapi id 14.02.0283.003; Wed, 1 Aug 2012 13:57:14 +0800 From: "Fan, Huaxiang" To: "xen-users@lists.xen.org" Thread-Topic: PCI passthrough for domU allocated with more than 4G memory Thread-Index: Ac1vp0xm5UJayF9xRx2DE9F/z2HnhA== Date: Wed, 1 Aug 2012 05:57:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.134.111] MIME-Version: 1.0 X-Scanned-By: MailControl 8316.0 (www.mailcontrol.com) on 10.72.1.139 Cc: "Konrad Rzeszutek Wilk \(konrad.wilk@oracle.com\)" , "xen-devel@lists.xen.org" Subject: [Xen-devel] PCI passthrough for domU allocated with more than 4G memory X-BeenThere: xen-devel@lists.xen.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="===============6773783635368204994==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6773783635368204994== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E71FC5D6F96C3C4B93FC8FF942D924C675ADD043SBJEXCH1Awebsen_" --_000_E71FC5D6F96C3C4B93FC8FF942D924C675ADD043SBJEXCH1Awebsen_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have encountered some strange problems when I was trying to PCI passthrou= gh Broadcom 5709/5716 NICs to domUs allocated with more than 4G memory. Ple= ase see below for details. My environment is: Hardware Platform: DELL R210 with 2 Broadcom 5709 NICs and 2 Broadcom 5716 = NICs Xen: xen 4.2 unstable (64bits for hypervisor and 32bit for tools) Kernel for both dom0 and domUs: xenified kernel 2.6.32.57 (32bit) OS: CentOS 6.2 (32bit) The general info regarding to xen can be get via below command # xl info host : 7.8 release : 2.6.32.57 version : #1 SMP Fri Jul 6 18:44:16 CST 2012 machine : i686 nr_cpus : 8 max_cpu_id : 31 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 2 cpu_mhz : 2660 hw_caps : bfebfbff:28100800:00000000:00003b40:0098e3fd:00000= 000:00000001:00000000 virt_caps : hvm hvm_directio total_memory : 8182 free_memory : 7046 sharing_freed_memory : 0 sharing_used_memory : 0 free_cpus : 0 xen_major : 4 xen_minor : 2 xen_extra : -unstable xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-= 3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=3D0xff400000 xen_changeset : unavailable xen_commandline : dom0_mem=3D1024M dom0_max_vcpus=3D2 dom0_vcpus_pin cc_compiler : gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) cc_compile_by : root cc_compile_domain : cc_compile_date : Thu Jul 12 11:20:56 CST 2012 xend_config_format : 4 case 1> I specified PV-domU config as below memory=3D3072 maxmem=3D6144 name=3D"bs" vif=3D['ip=3D169.254.254.1,script=3Dvif-nat',] disk=3D['file:/root/bs.img,xvda1,w'] kernel=3D'/root/vmlinuz' extra=3D"iommu=3Dsoft console=3Dhvc0" ramdisk=3D'/root/initrd.img' root=3D"/dev/xvda1 ro" pci=3D['01:00.0','01:00.1'] and then start domU. After that I executed below command # xl list Name ID Mem VCPUs State Tim= e(s) Domain-0 0 1024 2 r----- = 88.7 bs 2 3072 1 -b---- = 1.1 It seemed normal to me. But when I logon bs domU, and executed below command # cat /proc/meminfo | head MemTotal: 6158940 kB MemFree: 2944776 kB Buffers: 5108 kB Cached: 32292 kB SwapCached: 0 kB Active: 21456 kB Inactive: 22936 kB Active(anon): 7000 kB Inactive(anon): 108 kB Active(file): 14456 kB It indicated the total memory was 6G, why? When I back to dom0, I executed below command # xl mem-set bs 6144 # xl list Name ID Mem VCPUs State Tim= e(s) Domain-0 0 1024 2 r----- = 93.5 bs 2 6144 1 -b---- = 10.5 It seemed normal to me. But when I logon bs domU again and executed below c= ommand # cat /proc/meminfo | head MemTotal: 9304668 kB MemFree: 6087540 kB Buffers: 5168 kB Cached: 32464 kB SwapCached: 0 kB Active: 22300 kB Inactive: 22408 kB Active(anon): 7080 kB Inactive(anon): 108 kB Active(file): 15220 kB It indicated total memory was 9G (6G + 3G). It was wired. Any idea about th= is? Case 2> I specified PV-domU config as below memory=3D6144 maxmem=3D6144 name=3D"bs" vif=3D['ip=3D169.254.254.1,script=3Dvif-nat',] disk=3D['file:/root/bs.img,xvda1,w'] kernel=3D'/root/vmlinuz' extra=3D"iommu=3Dsoft console=3Dhvc0" ramdisk=3D'/root/initrd.img' root=3D"/dev/xvda1 ro" pci=3D['01:00.0','01:00.1'] and then start domU. After that I executed below command # xl list Name ID Mem VCPUs State Tim= e(s) Domain-0 0 648 2 r----- 1= 20.5 bs 3 3360 1 -b---- = 7.0 the output was very confusing. Why dom0 memory had been shrank to 648M and = only 3360M assigned to bs domU? My own analysis: I extracted the bios e820 memory map on bs domU as below [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 00000000000a0000 (usable) [ 0.000000] Xen: 00000000000a0000 - 0000000000100000 (reserved) [ 0.000000] Xen: 0000000000100000 - 00000000bf699000 (usable) [ 0.000000] Xen: 00000000bf699000 - 00000000bf6af000 (reserved) [ 0.000000] Xen: 00000000bf6af000 - 00000000bf6ce000 (ACPI data) [ 0.000000] Xen: 00000000bf6ce000 - 00000000c0000000 (reserved) [ 0.000000] Xen: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] Xen: 00000000fe000000 - 0000000100000000 (reserved) [ 0.000000] Xen: 0000000180000000 - 00000001c33ec000 (usable) I think the root cause might be related to the holes between c0000000 and e= 0000000 and between f0000000 and fe000000 and between 100000000 and 1800000= 00. And I think the e820_host option set according to my tracking. Thanks in advance HUAXIANG FAN Software Engineer II WEBSENSE NETWORK SECURITY TECHNOLOGY R&D (BEIJING) CO. LTD. ph: +8610.5884.4327 fax: +8610.5884.4727 www.websense.cn Websense TRITON(tm) For Essential Information Protection(tm) Web Security | Data Security | Email Security Protected by Websense Hosted Email Security -- www.websense.com=20 --_000_E71FC5D6F96C3C4B93FC8FF942D924C675ADD043SBJEXCH1Awebsen_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have encountered some strange problems when I was = trying to PCI passthrough Broadcom 5709/5716 NICs to domUs allocated with m= ore than 4G memory. Please see below for details.

 

My environment is:

Hardware Platform: DELL R210 with 2 Broadcom 5709 NI= Cs and 2 Broadcom 5716 NICs

Xen: xen 4.2 unstable (64bits for hypervisor and 32b= it for tools)

Kernel for both dom0 and domUs: xenified kernel 2.6.= 32.57 (32bit)

OS: CentOS 6.2 (32bit)

 

The general info regarding to xen can be get via bel= ow command

# xl info

host       &nb= sp;           : 7.8<= /o:p>

release       =          : 2.6.32.57

version       =          : #1 SMP Fri Jul 6 18:44:1= 6 CST 2012

machine       =          : i686

nr_cpus       =          : 8

max_cpu_id      &nb= sp;      : 31

nr_nodes       = ;        : 1

cores_per_socket     &nb= sp; : 4

threads_per_core     &nb= sp; : 2

cpu_mhz       =          : 2660

hw_caps       =          : bfebfbff:28100800:000000= 00:00003b40:0098e3fd:00000000:00000001:00000000

virt_caps      &nbs= p;       : hvm hvm_directio

total_memory      &= nbsp;    : 8182

free_memory      &n= bsp;     : 7046

sharing_freed_memory   : 0

sharing_used_memory    : 0

free_cpus      &nbs= p;       : 0

xen_major      &nbs= p;       : 4

xen_minor      &nbs= p;       : 2

xen_extra      &nbs= p;       : -unstable

xen_caps       = ;        : xen-3.0-x86_64 xen-3.0-x86_32= p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64

xen_scheduler      =     : credit

xen_pagesize      &= nbsp;    : 4096

platform_params     &nbs= p;  : virt_start=3D0xff400000

xen_changeset      =     : unavailable

xen_commandline     &nbs= p;  : dom0_mem=3D1024M dom0_max_vcpus=3D2 dom0_vcpus_pin

cc_compiler      &n= bsp;     : gcc version 4.4.6 20110731 (Red Hat 4.4.6-3)= (GCC)

cc_compile_by      =     : root

cc_compile_domain      :=

cc_compile_date     &nbs= p;  : Thu Jul 12 11:20:56 CST 2012

xend_config_format     : 4

 

case 1> I specified PV-domU config as below<= /o:p>

memory=3D3072

maxmem=3D6144

name=3D"bs"

vif=3D['ip=3D169.254.254.1,script=3Dvif-nat',]

disk=3D['file:/root/bs.img,xvda1,w']

kernel=3D'/root/vmlinuz'

extra=3D"iommu=3Dsoft console=3Dhvc0"

ramdisk=3D'/root/initrd.img'

root=3D"/dev/xvda1 ro"

pci=3D['01:00.0','01:00.1']

 

and then start domU. After that I executed below com= mand

# xl list

Name       &nb= sp;            =             &nb= sp;       ID   Mem VCPUs  = ;    State   Time(s)

Domain-0       = ;            &n= bsp;            = ;     0  1024     2  = ;   r-----      88.7

bs        = ;            &n= bsp;            &nbs= p;         2  3072 &= nbsp;   1     -b----    &= nbsp;  1.1

 

It seemed normal to me. But when I logon bs domU, an= d executed below command

# cat /proc/meminfo | head

MemTotal:      &nbs= p; 6158940 kB

MemFree:       = ;  2944776 kB

Buffers:       = ;     5108 kB

Cached:       =      32292 kB

SwapCached:      &n= bsp;     0 kB

Active:       =      21456 kB

Inactive:      &nbs= p;   22936 kB

Active(anon):      = 7000 kB

Inactive(anon):      108= kB

Active(file):      14456= kB

 

It indicated the total memory was 6G, why?

When I back to dom0, I executed below command

# xl mem-set bs 6144

# xl list

Name       &nb= sp;            =             &nb= sp;       ID   Mem VCPUs  = ;    State   Time(s)

Domain-0       = ;            &n= bsp;            = ;     0  1024     2  = ;   r-----      93.5

bs        = ;            &n= bsp;            = ;          2  6144 &= nbsp;   1     -b----    &= nbsp; 10.5

It seemed normal to me. But when I logon bs domU aga= in and executed below command

# cat /proc/meminfo | head

MemTotal:      &nbs= p; 9304668 kB

MemFree:       = ;  6087540 kB

Buffers:       = ;     5168 kB

Cached:       =      32464 kB

SwapCached:      &n= bsp;     0 kB

Active:       =      22300 kB

Inactive:      &nbs= p;   22408 kB

Active(anon):      = 7080 kB

Inactive(anon):      108= kB

Active(file):      15220= kB

 

It indicated total memory was 9G (6G + 3G). I= t was wired. Any idea about this?

Case 2> I specified PV-domU config as below<= /o:p>

memory=3D6144

maxmem=3D6144

name=3D"bs"

vif=3D['ip=3D169.254.254.1,script=3Dvif-nat',]

disk=3D['file:/root/bs.img,xvda1,w']

kernel=3D'/root/vmlinuz'

extra=3D"iommu=3Dsoft console=3Dhvc0"

ramdisk=3D'/root/initrd.img'

root=3D"/dev/xvda1 ro"

pci=3D['01:00.0','01:00.1']

 

and then start domU. After that I executed below com= mand

# xl list

Name       &nb= sp;            =             &nb= sp;       ID   Mem VCPUs  = ;    State   Time(s)

Domain-0       = ;            &n= bsp;            = ;     0   648     2 =     r-----     120.5

bs        = ;            &n= bsp;            = ;          3  3360 &= nbsp;   1     -b----    &= nbsp;  7.0

 

the output was very confusing. Why dom0 memory had b= een shrank to 648M and only 3360M assigned to bs domU?

 

My own analysis:

I extracted the bios e820 memory map on bs domU as b= elow

[    0.000000] BIOS-provided physi= cal RAM map:

[    0.000000]  Xen: 00000000= 00000000 - 00000000000a0000 (usable)

[    0.000000]  Xen: 00000000= 000a0000 - 0000000000100000 (reserved)

[    0.000000]  Xen: 00000000= 00100000 - 00000000bf699000 (usable)

[    0.000000]  Xen: 00000000= bf699000 - 00000000bf6af000 (reserved)

[    0.000000]  Xen: 00000000= bf6af000 - 00000000bf6ce000 (ACPI data)

[    0.000000]  Xen: 00000000= bf6ce000 - 00000000c0000000 (reserved)

[    0.000000]  Xen: 00000000= e0000000 - 00000000f0000000 (reserved)

[    0.000000]  Xen: 00000000= fe000000 - 0000000100000000 (reserved)

[    0.000000]  Xen: 00000001= 80000000 - 00000001c33ec000 (usable)

 

I think the root cause might be related to the holes= between c0000000 and e0000000 and between f0000000 and fe000000 and betwee= n 100000000 and 180000000. And I think the e820_host option set according t= o my tracking.

 

Thanks in advance

HUAXIANG FAN
Software Engineer II

WEBSENSE NETWORK SECURITY TECHNOLOGY R&am= p;D (BEIJING) CO. LTD.
ph: +8610.5884.4327
fax: +8610.5884.4727
www.websense.cn

Websense TRITON™
For Essential Information Protection™
Web Security | = Data Security= | Email Security



Protected by Websense Hosted Email Security = 212; www.websense.com

--_000_E71FC5D6F96C3C4B93FC8FF942D924C675ADD043SBJEXCH1Awebsen_-- --===============6773783635368204994== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6773783635368204994==-- From xen-devel-bounces@lists.xen.org Wed Aug 01 06:43:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 06: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 1SwSdu-0005mr-GL; Wed, 01 Aug 2012 06:42:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwSds-0005mm-JQ for xen-devel@lists.xensource.com; Wed, 01 Aug 2012 06:42:48 +0000 Received: from [85.158.143.99:52732] by server-3.bemta-4.messagelabs.com id 5A/21-01511-7EFC8105; Wed, 01 Aug 2012 06:42:47 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1343803366!26322869!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDc2Mjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13975 invoked from network); 1 Aug 2012 06:42:47 -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 Aug 2012 06:42:47 -0000 X-IronPort-AV: E=Sophos;i="4.77,691,1336348800"; d="scan'208";a="13795248" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Aug 2012 06:42:46 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Aug 2012 07:42:46 +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 1SwSdp-0002ch-VW; Wed, 01 Aug 2012 06:42:46 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SwSdp-0004fm-R7; Wed, 01 Aug 2012 07:42:45 +0100 To: Message-ID: From: xen.org Date: Wed, 1 Aug 2012 07:42:45 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13533: 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 13533 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13533/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13527 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13527 test-i386-i386-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13527 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13527 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-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-xl-win7-amd64 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen cf0e661cb321 baseline version: xen cf0e661cb321 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass 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 pass 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 pass test-amd64-i386-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 Wed Aug 01 06:43:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 06: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 1SwSdu-0005mr-GL; Wed, 01 Aug 2012 06:42:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwSds-0005mm-JQ for xen-devel@lists.xensource.com; Wed, 01 Aug 2012 06:42:48 +0000 Received: from [85.158.143.99:52732] by server-3.bemta-4.messagelabs.com id 5A/21-01511-7EFC8105; Wed, 01 Aug 2012 06:42:47 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1343803366!26322869!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDc2Mjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13975 invoked from network); 1 Aug 2012 06:42:47 -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 Aug 2012 06:42:47 -0000 X-IronPort-AV: E=Sophos;i="4.77,691,1336348800"; d="scan'208";a="13795248" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Aug 2012 06:42:46 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Aug 2012 07:42:46 +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 1SwSdp-0002ch-VW; Wed, 01 Aug 2012 06:42:46 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1SwSdp-0004fm-R7; Wed, 01 Aug 2012 07:42:45 +0100 To: Message-ID: From: xen.org Date: Wed, 1 Aug 2012 07:42:45 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13533: 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 13533 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13533/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13527 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13527 test-i386-i386-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13527 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13527 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-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-xl-win7-amd64 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen cf0e661cb321 baseline version: xen cf0e661cb321 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass 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 pass 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 pass test-amd64-i386-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 Wed Aug 01 07:49:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 07:49:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwTg5-0006s3-QL; Wed, 01 Aug 2012 07: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 1SwTg4-0006rx-LQ for xen-devel@lists.xen.org; Wed, 01 Aug 2012 07:49:08 +0000 Received: from [85.158.139.83:22967] by server-9.bemta-5.messagelabs.com id 1C/48-01069-37FD8105; Wed, 01 Aug 2012 07:49:07 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1343807347!26977002!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27476 invoked from network); 1 Aug 2012 07:49:07 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-182.messagelabs.com with SMTP; 1 Aug 2012 07:49:07 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 01 Aug 2012 08:49:06 +0100 Message-Id: <5018FBB60200007800091CCB@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 01 Aug 2012 08:49:42 +0100 From: "Jan Beulich" To: "Andrew Cooper" , "Ian Jackson" References: <20504.3594.340410.435942@mariner.uk.xensource.com> In-Reply-To: <20504.3594.340410.435942@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Keir \(Xen.org\)" , Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 4 of 5] xen/makefile: Allow XEN_CHANGESET to be set externally X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/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.07.12 at 18:55, Ian Jackson wrote: > Andrew Cooper writes ("[PATCH 4 of 5] xen/makefile: Allow XEN_CHANGESET to be > set externally"): > .. >> diff -r 6db5c184a777 -r ae32690d0d74 xen/Makefile >> --- a/xen/Makefile >> +++ b/xen/Makefile >> @@ -13,6 +13,7 @@ export BASEDIR := $(CURDIR) >> export XEN_ROOT := $(BASEDIR)/.. >> >> EFI_MOUNTPOINT ?= /boot/efi >> +XEN_CHANGESET ?= $(shell hg root &> /dev/null && hg parents --template > "{date|date} {rev}:{node|short}" || echo "unavailable" ) >> >> .PHONY: default >> default: build >> @@ -107,7 +108,7 @@ include/xen/compile.h: include/xen/compi >> -e 's/@@version@@/$(XEN_VERSION)/g' \ >> -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \ >> -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \ >> - -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date} > {rev}:{node|short}" >/dev/null && hg parents --template "{date|date} > {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \ >> + -e 's!@@changeset@@!$(XEN_CHANGESET)!g' \ >> < include/xen/compile.h.in > $@.new >> @grep \" .banner >> $@.new >> @grep -v \" .banner > > We need to check how many times, and at which point, this gets > executed, when this patch is applied. I think it's OK... If in doubt, perhaps the better option would be to execute this once unconditionally (via := assignment to a helper variable), or to use := here but frame the assignment with some if construct excluding it to be executed when the changeset was already specified (assuming that an empty specification is pointless, simply checking for it to be non-empty 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 Wed Aug 01 07:49:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 07:49:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwTg5-0006s3-QL; Wed, 01 Aug 2012 07: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 1SwTg4-0006rx-LQ for xen-devel@lists.xen.org; Wed, 01 Aug 2012 07:49:08 +0000 Received: from [85.158.139.83:22967] by server-9.bemta-5.messagelabs.com id 1C/48-01069-37FD8105; Wed, 01 Aug 2012 07:49:07 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1343807347!26977002!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27476 invoked from network); 1 Aug 2012 07:49:07 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-182.messagelabs.com with SMTP; 1 Aug 2012 07:49:07 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 01 Aug 2012 08:49:06 +0100 Message-Id: <5018FBB60200007800091CCB@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 01 Aug 2012 08:49:42 +0100 From: "Jan Beulich" To: "Andrew Cooper" , "Ian Jackson" References: <20504.3594.340410.435942@mariner.uk.xensource.com> In-Reply-To: <20504.3594.340410.435942@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Keir \(Xen.org\)" , Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 4 of 5] xen/makefile: Allow XEN_CHANGESET to be set externally X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/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.07.12 at 18:55, Ian Jackson wrote: > Andrew Cooper writes ("[PATCH 4 of 5] xen/makefile: Allow XEN_CHANGESET to be > set externally"): > .. >> diff -r 6db5c184a777 -r ae32690d0d74 xen/Makefile >> --- a/xen/Makefile >> +++ b/xen/Makefile >> @@ -13,6 +13,7 @@ export BASEDIR := $(CURDIR) >> export XEN_ROOT := $(BASEDIR)/.. >> >> EFI_MOUNTPOINT ?= /boot/efi >> +XEN_CHANGESET ?= $(shell hg root &> /dev/null && hg parents --template > "{date|date} {rev}:{node|short}" || echo "unavailable" ) >> >> .PHONY: default >> default: build >> @@ -107,7 +108,7 @@ include/xen/compile.h: include/xen/compi >> -e 's/@@version@@/$(XEN_VERSION)/g' \ >> -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \ >> -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \ >> - -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date} > {rev}:{node|short}" >/dev/null && hg parents --template "{date|date} > {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \ >> + -e 's!@@changeset@@!$(XEN_CHANGESET)!g' \ >> < include/xen/compile.h.in > $@.new >> @grep \" .banner >> $@.new >> @grep -v \" .banner > > We need to check how many times, and at which point, this gets > executed, when this patch is applied. I think it's OK... If in doubt, perhaps the better option would be to execute this once unconditionally (via := assignment to a helper variable), or to use := here but frame the assignment with some if construct excluding it to be executed when the changeset was already specified (assuming that an empty specification is pointless, simply checking for it to be non-empty 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 Wed Aug 01 07:54:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 07:54:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwTkB-0006zj-Ij; Wed, 01 Aug 2012 07:53:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwTgU-0006sz-8M for xen-devel@lists.xen.org; Wed, 01 Aug 2012 07:49:34 +0000 Received: from [85.158.139.83:24818] by server-4.bemta-5.messagelabs.com id 96/A5-27831-D8FD8105; Wed, 01 Aug 2012 07:49:33 +0000 X-Env-Sender: t.wagner@inode.at X-Msg-Ref: server-10.tower-182.messagelabs.com!1343807371!29959999!1 X-Originating-IP: [213.47.214.141] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9326 invoked from network); 1 Aug 2012 07:49:32 -0000 Received: from webmail.inode.at (HELO webmail.inode.at) (213.47.214.141) by server-10.tower-182.messagelabs.com with SMTP; 1 Aug 2012 07:49:32 -0000 Received: from [127.0.0.1] (helo=inode.at) by webmail with smtp (Exim 4.67) (envelope-from ) id 1SwTgR-0003VH-Je for xen-devel@lists.xen.org; Wed, 01 Aug 2012 09:49:31 +0200 Received: from 85.126.176.235 (SquirrelMail authenticated user t.wagner@inode.at) by webmail.inode.at with HTTP; Wed, 1 Aug 2012 09:49:31 +0200 (CEST) Message-ID: <85.126.176.235.1343807371.wm@webmail.inode.at> Date: Wed, 1 Aug 2012 09:49:31 +0200 (CEST) From: "Dipl.-Ing. Thomas Wagner" To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 01 Aug 2012 07:53:22 +0000 Subject: [Xen-devel] XEN 4.1.2 and kernel 3.4.7 X-BeenThere: xen-devel@lists.xen.org X-Mailman-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 Once or twice a day I get a kernel trace in dom0 like this. Aug 1 05:52:08 zeus kernel: INFO: rcu_bh self-detected stall on CPU { 3} = (t=3D0 jiffies) Aug 1 05:52:08 zeus kernel: Pid: 0, comm: swapper/3 Not tainted 3.4.7-4-xen #1 Aug 1 05:52:08 zeus kernel: Call Trace: Aug 1 05:52:08 zeus kernel: [] ? __rcu_pending+0x1a1/0x4b0 Aug 1 05:52:08 zeus kernel: [] ? tick_init_highres+0x10/0x10 Aug 1 05:52:08 zeus kernel: [] ? rcu_check_callbacks+0xbb/0xd0 Aug 1 05:52:08 zeus kernel: [] ? update_process_times+0x3f/0x80 Aug 1 05:52:08 zeus kernel: [] ? tick_sched_timer+0x54/0x130 Aug 1 05:52:08 zeus kernel: [] ? __run_hrtimer.isra.34+0x59/0xf0 Aug 1 05:52:08 zeus kernel: [] ? hrtimer_interrupt+0xec/0x230 Aug 1 05:52:08 zeus kernel: [] ? xen_timer_interrupt+0x2a/0x1a0 Aug 1 05:52:08 zeus kernel: [] ? cascade+0x73/0x90 Aug 1 05:52:08 zeus kernel: [] ? handle_irq_event_percpu+0x3a/0x150 Aug 1 05:52:08 zeus kernel: [] ? handle_percpu_irq+0x3f/0x70 Aug 1 05:52:08 zeus kernel: [] ? __do_softirq+0xbd/0x130 Aug 1 05:52:08 zeus kernel: [] ? __xen_evtchn_do_upcall+0x194/0x240 Aug 1 05:52:08 zeus kernel: [] ? xen_evtchn_do_upcall+0x22/0x40 Aug 1 05:52:08 zeus kernel: [] ? xen_do_hypervisor_callback+0x1e/0x30 Aug 1 05:52:08 zeus kernel: [] ? hypercall_page+0x3aa/0x1000 Aug 1 05:52:08 zeus kernel: [] ? hypercall_page+0x3aa/0x1000 Aug 1 05:52:08 zeus kernel: [] ? xen_safe_halt+0xc/0x20 Aug 1 05:52:08 zeus kernel: [] ? default_idle+0x23/0x40 Aug 1 05:52:08 zeus kernel: [] ? cpu_idle+0xa6/0xc0 Im am using a HP DL585 G2 running openSuse 12.1. zeus:~ # xm info host : zeus release : 3.4.7-4-xen version : #1 SMP Mon Jul 30 15:31:08 CEST 2012 machine : x86_64 nr_cpus : 8 nr_nodes : 4 cores_per_socket : 2 threads_per_core : 1 cpu_mhz : 2612 hw_caps : 178bf3ff:ebc3fbff:00000000:00000010:00002001:00000000:0000001f:00000000 virt_caps : hvm total_memory : 24572 free_memory : 14810 free_cpus : 0 max_free_memory : 14810 max_para_memory : 14806 max_hvm_memory : 14763 xen_major : 4 xen_minor : 1 xen_extra : .2_17-199.1 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=3D0xffff800000000000 xen_changeset : 23174 xen_commandline : dom0_mem=3Dmax:768M cc_compiler : gcc version 4.6.2 (SUSE Linux) cc_compile_by : abuild cc_compile_domain : cc_compile_date : Tue Jul 10 14:09:23 UTC 2012 xend_config_format : 4 zeus:~ # xm dmesg __ __ _ _ _ ____ _ _____ _ ___ ___ _ \ \/ /___ _ __ | || | / | |___ \ / |___ |/ |/ _ \ / _ \ / | \ // _ \ '_ \ | || |_ | | __) | | | / /_| | (_) | (_) || | / \ __/ | | | |__ _|| |_ / __/ | | / /__| |\__, |\__, || | /_/\_\___|_| |_| |_|(_)_(_)_____|___|_|/_/ |_| /_/ /_(_)_| |_____| (XEN) Xen version 4.1.2_17-199.1 (abuild@) (gcc version 4.6.2 (SUSE Linux) ) Tue Jul 10 14:09:23 UTC 2012 (XEN) Latest ChangeSet: 23174 (XEN) Bootloader: GNU GRUB 0.97 (XEN) Command line: dom0_mem=3Dmax:768M (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 2 seconds (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009f400 (usable) (XEN) 000000000009f400 - 00000000000a0000 (reserved) (XEN) 00000000000f0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 000000007fd4e000 (usable) (XEN) 000000007fd4e000 - 000000007fd56000 (ACPI data) (XEN) 000000007fd56000 - 000000007fd57000 (usable) (XEN) 000000007fd57000 - 0000000080000000 (reserved) (XEN) 00000000e0000000 - 00000000f0000000 (reserved) (XEN) 00000000fec00000 - 00000000fed00000 (reserved) (XEN) 00000000fee00000 - 00000000fee10000 (reserved) (XEN) 00000000ffc00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 000000067ffff000 (usable) (XEN) ACPI: RSDP 000F4F00, 0024 (r2 HP ) (XEN) ACPI: XSDT 7FD4ED80, 0074 (r1 HP ProLiant 2 =D2 162E) (XEN) ACPI: FACP 7FD4EE00, 00F4 (r3 HP A07 2 =D2 162E) (XEN) ACPI: DSDT 7FD4EF00, 4A6D (r1 HP DSDT 1 INTL 20030228) (XEN) ACPI: FACS 7FD4E100, 0040 (XEN) ACPI: SPCR 7FD4E140, 0050 (r1 HP SPCRRBSU 1 =D2 162E) (XEN) ACPI: HPET 7FD4E1C0, 0038 (r1 HP ProLiant 2 =D2 162E) (XEN) ACPI: SPMI 7FD4E200, 0040 (r5 HP ProLiant 1 =D2 162E) (XEN) ACPI: ERST 7FD4E240, 01D0 (r1 HP ProLiant 1 =D2 162E) (XEN) ACPI: APIC 7FD4E440, 00C6 (r1 HP ProLiant 2 0) (XEN) ACPI: SRAT 7FD4E600, 01A0 (r1 AMD FAM_F_10 2 AMD 1) (XEN) ACPI: FFFF 7FD4EA00, 0176 (r1 HP ProLiant 1 =D2 162E) (XEN) ACPI: BERT 7FD4EB80, 0030 (r1 HP ProLiant 1 =D2 162E) (XEN) ACPI: HEST 7FD4EBC0, 0170 (r1 HP ProLiant 1 =D2 162E) (XEN) System RAM: 24572MB (25162676kB) (XEN) Domain heap initialised DMA width 31 bits (XEN) Processor #0 15:1 APIC version 16 (XEN) Processor #2 15:1 APIC version 16 (XEN) Processor #4 15:1 APIC version 16 (XEN) Processor #6 15:1 APIC version 16 (XEN) Processor #1 15:1 APIC version 16 (XEN) Processor #3 15:1 APIC version 16 (XEN) Processor #5 15:1 APIC version 16 (XEN) Processor #7 15:1 APIC version 16 (XEN) IOAPIC[0]: apic_id 8, version 17, address 0xd9af0000, GSI 0-23 (XEN) IOAPIC[1]: apic_id 9, version 17, address 0xd9fd0000, GSI 24-30 (XEN) IOAPIC[2]: apic_id 10, version 17, address 0xd9fe0000, GSI 31-37 (XEN) IOAPIC[3]: apic_id 11, version 17, address 0xd9ff0000, GSI 38-61 (XEN) Enabling APIC mode: Flat. Using 4 I/O APICs (XEN) ERST table is invalid (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2612.090 MHz processor. (XEN) Initing memory sharing. (XEN) AMD-Vi: IOMMU not found! (XEN) I/O virtualisation disabled (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) Platform timer is 25.000MHz HPET (XEN) Allocated console ring of 16 KiB. (XEN) HVM: ASIDs disabled. (XEN) SVM: Supported advanced features: (XEN) - none (XEN) HVM: SVM enabled (XEN) AMD: Disabling C1 Clock Ramping Node #0 (XEN) AMD: Disabling C1 Clock Ramping Node #1 (XEN) AMD: Disabling C1 Clock Ramping Node #2 (XEN) AMD: Disabling C1 Clock Ramping Node #3 (XEN) Brought up 8 CPUs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1a01000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 000000043c000000->000000043e000000 (182523 pages to be allocated) (XEN) Init. ramdisk: 000000067e6fb000->000000067fdffa00 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81a01000 (XEN) Init. ramdisk: ffffffff81a01000->ffffffff83105a00 (XEN) Phys-Mach map: ffffffff83106000->ffffffff83286000 (XEN) Start info: ffffffff83286000->ffffffff832864b4 (XEN) Page tables: ffffffff83287000->ffffffff832a4000 (XEN) Boot stack: ffffffff832a4000->ffffffff832a5000 (XEN) TOTAL: ffffffff80000000->ffffffff83400000 (XEN) ENTRY ADDRESS: ffffffff81496200 (XEN) Dom0 has maximum 8 VCPUs (XEN) Scrubbing Free RAM: ...........................................................................= ...........................................................................= ...........................................................................= .........done. (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 232kB init memory. (XEN) traps.c:2527:d0 Domain attempted WRMSR 00000000c0010004 from 0x0000d6be5955d450 to 0x000000000000abcd. (XEN) physdev.c:159: dom0: wrong map_pirq type 3 (XEN) traps.c:2527:d1 Domain attempted WRMSR 00000000c0010004 from 0x0000d6be5955d450 to 0x000000000000abcd. (XEN) traps.c:2527:d2 Domain attempted WRMSR 00000000c0010004 from 0x0000a5bc3314d6f8 to 0x000000000000abcd. (XEN) traps.c:2527:d3 Domain attempted WRMSR 00000000c0010004 from 0x000092bdbb01c033 to 0x000000000000abcd. (XEN) traps.c:2527:d4 Domain attempted WRMSR 00000000c0010004 from 0x000095bff892b9bd to 0x000000000000abcd. There are some linux guests (running kernel 3.4.6) and Windows systems. I don't see any problems in the guest logs at these moments. Anybody else has these problems too? regards Thomas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 07:54:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 07:54:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwTkB-0006zj-Ij; Wed, 01 Aug 2012 07:53:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwTgU-0006sz-8M for xen-devel@lists.xen.org; Wed, 01 Aug 2012 07:49:34 +0000 Received: from [85.158.139.83:24818] by server-4.bemta-5.messagelabs.com id 96/A5-27831-D8FD8105; Wed, 01 Aug 2012 07:49:33 +0000 X-Env-Sender: t.wagner@inode.at X-Msg-Ref: server-10.tower-182.messagelabs.com!1343807371!29959999!1 X-Originating-IP: [213.47.214.141] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9326 invoked from network); 1 Aug 2012 07:49:32 -0000 Received: from webmail.inode.at (HELO webmail.inode.at) (213.47.214.141) by server-10.tower-182.messagelabs.com with SMTP; 1 Aug 2012 07:49:32 -0000 Received: from [127.0.0.1] (helo=inode.at) by webmail with smtp (Exim 4.67) (envelope-from ) id 1SwTgR-0003VH-Je for xen-devel@lists.xen.org; Wed, 01 Aug 2012 09:49:31 +0200 Received: from 85.126.176.235 (SquirrelMail authenticated user t.wagner@inode.at) by webmail.inode.at with HTTP; Wed, 1 Aug 2012 09:49:31 +0200 (CEST) Message-ID: <85.126.176.235.1343807371.wm@webmail.inode.at> Date: Wed, 1 Aug 2012 09:49:31 +0200 (CEST) From: "Dipl.-Ing. Thomas Wagner" To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 01 Aug 2012 07:53:22 +0000 Subject: [Xen-devel] XEN 4.1.2 and kernel 3.4.7 X-BeenThere: xen-devel@lists.xen.org X-Mailman-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 Once or twice a day I get a kernel trace in dom0 like this. Aug 1 05:52:08 zeus kernel: INFO: rcu_bh self-detected stall on CPU { 3} = (t=3D0 jiffies) Aug 1 05:52:08 zeus kernel: Pid: 0, comm: swapper/3 Not tainted 3.4.7-4-xen #1 Aug 1 05:52:08 zeus kernel: Call Trace: Aug 1 05:52:08 zeus kernel: [] ? __rcu_pending+0x1a1/0x4b0 Aug 1 05:52:08 zeus kernel: [] ? tick_init_highres+0x10/0x10 Aug 1 05:52:08 zeus kernel: [] ? rcu_check_callbacks+0xbb/0xd0 Aug 1 05:52:08 zeus kernel: [] ? update_process_times+0x3f/0x80 Aug 1 05:52:08 zeus kernel: [] ? tick_sched_timer+0x54/0x130 Aug 1 05:52:08 zeus kernel: [] ? __run_hrtimer.isra.34+0x59/0xf0 Aug 1 05:52:08 zeus kernel: [] ? hrtimer_interrupt+0xec/0x230 Aug 1 05:52:08 zeus kernel: [] ? xen_timer_interrupt+0x2a/0x1a0 Aug 1 05:52:08 zeus kernel: [] ? cascade+0x73/0x90 Aug 1 05:52:08 zeus kernel: [] ? handle_irq_event_percpu+0x3a/0x150 Aug 1 05:52:08 zeus kernel: [] ? handle_percpu_irq+0x3f/0x70 Aug 1 05:52:08 zeus kernel: [] ? __do_softirq+0xbd/0x130 Aug 1 05:52:08 zeus kernel: [] ? __xen_evtchn_do_upcall+0x194/0x240 Aug 1 05:52:08 zeus kernel: [] ? xen_evtchn_do_upcall+0x22/0x40 Aug 1 05:52:08 zeus kernel: [] ? xen_do_hypervisor_callback+0x1e/0x30 Aug 1 05:52:08 zeus kernel: [] ? hypercall_page+0x3aa/0x1000 Aug 1 05:52:08 zeus kernel: [] ? hypercall_page+0x3aa/0x1000 Aug 1 05:52:08 zeus kernel: [] ? xen_safe_halt+0xc/0x20 Aug 1 05:52:08 zeus kernel: [] ? default_idle+0x23/0x40 Aug 1 05:52:08 zeus kernel: [] ? cpu_idle+0xa6/0xc0 Im am using a HP DL585 G2 running openSuse 12.1. zeus:~ # xm info host : zeus release : 3.4.7-4-xen version : #1 SMP Mon Jul 30 15:31:08 CEST 2012 machine : x86_64 nr_cpus : 8 nr_nodes : 4 cores_per_socket : 2 threads_per_core : 1 cpu_mhz : 2612 hw_caps : 178bf3ff:ebc3fbff:00000000:00000010:00002001:00000000:0000001f:00000000 virt_caps : hvm total_memory : 24572 free_memory : 14810 free_cpus : 0 max_free_memory : 14810 max_para_memory : 14806 max_hvm_memory : 14763 xen_major : 4 xen_minor : 1 xen_extra : .2_17-199.1 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=3D0xffff800000000000 xen_changeset : 23174 xen_commandline : dom0_mem=3Dmax:768M cc_compiler : gcc version 4.6.2 (SUSE Linux) cc_compile_by : abuild cc_compile_domain : cc_compile_date : Tue Jul 10 14:09:23 UTC 2012 xend_config_format : 4 zeus:~ # xm dmesg __ __ _ _ _ ____ _ _____ _ ___ ___ _ \ \/ /___ _ __ | || | / | |___ \ / |___ |/ |/ _ \ / _ \ / | \ // _ \ '_ \ | || |_ | | __) | | | / /_| | (_) | (_) || | / \ __/ | | | |__ _|| |_ / __/ | | / /__| |\__, |\__, || | /_/\_\___|_| |_| |_|(_)_(_)_____|___|_|/_/ |_| /_/ /_(_)_| |_____| (XEN) Xen version 4.1.2_17-199.1 (abuild@) (gcc version 4.6.2 (SUSE Linux) ) Tue Jul 10 14:09:23 UTC 2012 (XEN) Latest ChangeSet: 23174 (XEN) Bootloader: GNU GRUB 0.97 (XEN) Command line: dom0_mem=3Dmax:768M (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 2 seconds (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009f400 (usable) (XEN) 000000000009f400 - 00000000000a0000 (reserved) (XEN) 00000000000f0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 000000007fd4e000 (usable) (XEN) 000000007fd4e000 - 000000007fd56000 (ACPI data) (XEN) 000000007fd56000 - 000000007fd57000 (usable) (XEN) 000000007fd57000 - 0000000080000000 (reserved) (XEN) 00000000e0000000 - 00000000f0000000 (reserved) (XEN) 00000000fec00000 - 00000000fed00000 (reserved) (XEN) 00000000fee00000 - 00000000fee10000 (reserved) (XEN) 00000000ffc00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 000000067ffff000 (usable) (XEN) ACPI: RSDP 000F4F00, 0024 (r2 HP ) (XEN) ACPI: XSDT 7FD4ED80, 0074 (r1 HP ProLiant 2 =D2 162E) (XEN) ACPI: FACP 7FD4EE00, 00F4 (r3 HP A07 2 =D2 162E) (XEN) ACPI: DSDT 7FD4EF00, 4A6D (r1 HP DSDT 1 INTL 20030228) (XEN) ACPI: FACS 7FD4E100, 0040 (XEN) ACPI: SPCR 7FD4E140, 0050 (r1 HP SPCRRBSU 1 =D2 162E) (XEN) ACPI: HPET 7FD4E1C0, 0038 (r1 HP ProLiant 2 =D2 162E) (XEN) ACPI: SPMI 7FD4E200, 0040 (r5 HP ProLiant 1 =D2 162E) (XEN) ACPI: ERST 7FD4E240, 01D0 (r1 HP ProLiant 1 =D2 162E) (XEN) ACPI: APIC 7FD4E440, 00C6 (r1 HP ProLiant 2 0) (XEN) ACPI: SRAT 7FD4E600, 01A0 (r1 AMD FAM_F_10 2 AMD 1) (XEN) ACPI: FFFF 7FD4EA00, 0176 (r1 HP ProLiant 1 =D2 162E) (XEN) ACPI: BERT 7FD4EB80, 0030 (r1 HP ProLiant 1 =D2 162E) (XEN) ACPI: HEST 7FD4EBC0, 0170 (r1 HP ProLiant 1 =D2 162E) (XEN) System RAM: 24572MB (25162676kB) (XEN) Domain heap initialised DMA width 31 bits (XEN) Processor #0 15:1 APIC version 16 (XEN) Processor #2 15:1 APIC version 16 (XEN) Processor #4 15:1 APIC version 16 (XEN) Processor #6 15:1 APIC version 16 (XEN) Processor #1 15:1 APIC version 16 (XEN) Processor #3 15:1 APIC version 16 (XEN) Processor #5 15:1 APIC version 16 (XEN) Processor #7 15:1 APIC version 16 (XEN) IOAPIC[0]: apic_id 8, version 17, address 0xd9af0000, GSI 0-23 (XEN) IOAPIC[1]: apic_id 9, version 17, address 0xd9fd0000, GSI 24-30 (XEN) IOAPIC[2]: apic_id 10, version 17, address 0xd9fe0000, GSI 31-37 (XEN) IOAPIC[3]: apic_id 11, version 17, address 0xd9ff0000, GSI 38-61 (XEN) Enabling APIC mode: Flat. Using 4 I/O APICs (XEN) ERST table is invalid (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2612.090 MHz processor. (XEN) Initing memory sharing. (XEN) AMD-Vi: IOMMU not found! (XEN) I/O virtualisation disabled (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) Platform timer is 25.000MHz HPET (XEN) Allocated console ring of 16 KiB. (XEN) HVM: ASIDs disabled. (XEN) SVM: Supported advanced features: (XEN) - none (XEN) HVM: SVM enabled (XEN) AMD: Disabling C1 Clock Ramping Node #0 (XEN) AMD: Disabling C1 Clock Ramping Node #1 (XEN) AMD: Disabling C1 Clock Ramping Node #2 (XEN) AMD: Disabling C1 Clock Ramping Node #3 (XEN) Brought up 8 CPUs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1a01000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 000000043c000000->000000043e000000 (182523 pages to be allocated) (XEN) Init. ramdisk: 000000067e6fb000->000000067fdffa00 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81a01000 (XEN) Init. ramdisk: ffffffff81a01000->ffffffff83105a00 (XEN) Phys-Mach map: ffffffff83106000->ffffffff83286000 (XEN) Start info: ffffffff83286000->ffffffff832864b4 (XEN) Page tables: ffffffff83287000->ffffffff832a4000 (XEN) Boot stack: ffffffff832a4000->ffffffff832a5000 (XEN) TOTAL: ffffffff80000000->ffffffff83400000 (XEN) ENTRY ADDRESS: ffffffff81496200 (XEN) Dom0 has maximum 8 VCPUs (XEN) Scrubbing Free RAM: ...........................................................................= ...........................................................................= ...........................................................................= .........done. (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 232kB init memory. (XEN) traps.c:2527:d0 Domain attempted WRMSR 00000000c0010004 from 0x0000d6be5955d450 to 0x000000000000abcd. (XEN) physdev.c:159: dom0: wrong map_pirq type 3 (XEN) traps.c:2527:d1 Domain attempted WRMSR 00000000c0010004 from 0x0000d6be5955d450 to 0x000000000000abcd. (XEN) traps.c:2527:d2 Domain attempted WRMSR 00000000c0010004 from 0x0000a5bc3314d6f8 to 0x000000000000abcd. (XEN) traps.c:2527:d3 Domain attempted WRMSR 00000000c0010004 from 0x000092bdbb01c033 to 0x000000000000abcd. (XEN) traps.c:2527:d4 Domain attempted WRMSR 00000000c0010004 from 0x000095bff892b9bd to 0x000000000000abcd. There are some linux guests (running kernel 3.4.6) and Windows systems. I don't see any problems in the guest logs at these moments. Anybody else has these problems too? regards Thomas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 08:05:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 08:05:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwTvR-0007hr-GM; Wed, 01 Aug 2012 08:05:01 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwTvP-0007hm-HQ for xen-devel@lists.xen.org; Wed, 01 Aug 2012 08:04:59 +0000 Received: from [85.158.139.83:22551] by server-10.bemta-5.messagelabs.com id C3/5E-02190-A23E8105; Wed, 01 Aug 2012 08:04:58 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1343808298!29118965!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13504 invoked from network); 1 Aug 2012 08:04:58 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-182.messagelabs.com with SMTP; 1 Aug 2012 08:04:58 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 01 Aug 2012 09:04:57 +0100 Message-Id: <5018FF720200007800091CE3@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 01 Aug 2012 09:05:38 +0100 From: "Jan Beulich" To: "Dipl.-Ing. Thomas Wagner" References: <85.126.176.235.1343807371.wm@webmail.inode.at> In-Reply-To: <85.126.176.235.1343807371.wm@webmail.inode.at> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] XEN 4.1.2 and kernel 3.4.7 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/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.08.12 at 09:49, "Dipl.-Ing. Thomas Wagner" wrote: > Aug 1 05:52:08 zeus kernel: INFO: rcu_bh self-detected stall on CPU { 3} > (t=0 jiffies) > Aug 1 05:52:08 zeus kernel: Pid: 0, comm: swapper/3 Not tainted > 3.4.7-4-xen #1 > Aug 1 05:52:08 zeus kernel: Call Trace: > Aug 1 05:52:08 zeus kernel: [] ? > __rcu_pending+0x1a1/0x4b0 > Aug 1 05:52:08 zeus kernel: [] ? > tick_init_highres+0x10/0x10 > Aug 1 05:52:08 zeus kernel: [] ? > rcu_check_callbacks+0xbb/0xd0 > Aug 1 05:52:08 zeus kernel: [] ? > update_process_times+0x3f/0x80 > Aug 1 05:52:08 zeus kernel: [] ? > tick_sched_timer+0x54/0x130 > Aug 1 05:52:08 zeus kernel: [] ? > __run_hrtimer.isra.34+0x59/0xf0 > Aug 1 05:52:08 zeus kernel: [] ? > hrtimer_interrupt+0xec/0x230 > Aug 1 05:52:08 zeus kernel: [] ? > xen_timer_interrupt+0x2a/0x1a0 > Aug 1 05:52:08 zeus kernel: [] ? cascade+0x73/0x90 > Aug 1 05:52:08 zeus kernel: [] ? > handle_irq_event_percpu+0x3a/0x150 > Aug 1 05:52:08 zeus kernel: [] ? > handle_percpu_irq+0x3f/0x70 > Aug 1 05:52:08 zeus kernel: [] ? __do_softirq+0xbd/0x130 > Aug 1 05:52:08 zeus kernel: [] ? > __xen_evtchn_do_upcall+0x194/0x240 > Aug 1 05:52:08 zeus kernel: [] ? > xen_evtchn_do_upcall+0x22/0x40 > Aug 1 05:52:08 zeus kernel: [] ? > xen_do_hypervisor_callback+0x1e/0x30 > Aug 1 05:52:08 zeus kernel: [] ? > hypercall_page+0x3aa/0x1000 > Aug 1 05:52:08 zeus kernel: [] ? > hypercall_page+0x3aa/0x1000 > Aug 1 05:52:08 zeus kernel: [] ? xen_safe_halt+0xc/0x20 > Aug 1 05:52:08 zeus kernel: [] ? default_idle+0x23/0x40 > Aug 1 05:52:08 zeus kernel: [] ? cpu_idle+0xa6/0xc0 > > > Im am using a HP DL585 G2 running openSuse 12.1. Yet the above trace appears to be from a pv-ops kernel, which 12.1 doesn't include (nor does it ship a 3.4-based kernel in the first place). Please provide complete, consistent information. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 08:05:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 08:05:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwTvR-0007hr-GM; Wed, 01 Aug 2012 08:05:01 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwTvP-0007hm-HQ for xen-devel@lists.xen.org; Wed, 01 Aug 2012 08:04:59 +0000 Received: from [85.158.139.83:22551] by server-10.bemta-5.messagelabs.com id C3/5E-02190-A23E8105; Wed, 01 Aug 2012 08:04:58 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1343808298!29118965!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13504 invoked from network); 1 Aug 2012 08:04:58 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-182.messagelabs.com with SMTP; 1 Aug 2012 08:04:58 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 01 Aug 2012 09:04:57 +0100 Message-Id: <5018FF720200007800091CE3@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 01 Aug 2012 09:05:38 +0100 From: "Jan Beulich" To: "Dipl.-Ing. Thomas Wagner" References: <85.126.176.235.1343807371.wm@webmail.inode.at> In-Reply-To: <85.126.176.235.1343807371.wm@webmail.inode.at> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] XEN 4.1.2 and kernel 3.4.7 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/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.08.12 at 09:49, "Dipl.-Ing. Thomas Wagner" wrote: > Aug 1 05:52:08 zeus kernel: INFO: rcu_bh self-detected stall on CPU { 3} > (t=0 jiffies) > Aug 1 05:52:08 zeus kernel: Pid: 0, comm: swapper/3 Not tainted > 3.4.7-4-xen #1 > Aug 1 05:52:08 zeus kernel: Call Trace: > Aug 1 05:52:08 zeus kernel: [] ? > __rcu_pending+0x1a1/0x4b0 > Aug 1 05:52:08 zeus kernel: [] ? > tick_init_highres+0x10/0x10 > Aug 1 05:52:08 zeus kernel: [] ? > rcu_check_callbacks+0xbb/0xd0 > Aug 1 05:52:08 zeus kernel: [] ? > update_process_times+0x3f/0x80 > Aug 1 05:52:08 zeus kernel: [] ? > tick_sched_timer+0x54/0x130 > Aug 1 05:52:08 zeus kernel: [] ? > __run_hrtimer.isra.34+0x59/0xf0 > Aug 1 05:52:08 zeus kernel: [] ? > hrtimer_interrupt+0xec/0x230 > Aug 1 05:52:08 zeus kernel: [] ? > xen_timer_interrupt+0x2a/0x1a0 > Aug 1 05:52:08 zeus kernel: [] ? cascade+0x73/0x90 > Aug 1 05:52:08 zeus kernel: [] ? > handle_irq_event_percpu+0x3a/0x150 > Aug 1 05:52:08 zeus kernel: [] ? > handle_percpu_irq+0x3f/0x70 > Aug 1 05:52:08 zeus kernel: [] ? __do_softirq+0xbd/0x130 > Aug 1 05:52:08 zeus kernel: [] ? > __xen_evtchn_do_upcall+0x194/0x240 > Aug 1 05:52:08 zeus kernel: [] ? > xen_evtchn_do_upcall+0x22/0x40 > Aug 1 05:52:08 zeus kernel: [] ? > xen_do_hypervisor_callback+0x1e/0x30 > Aug 1 05:52:08 zeus kernel: [] ? > hypercall_page+0x3aa/0x1000 > Aug 1 05:52:08 zeus kernel: [] ? > hypercall_page+0x3aa/0x1000 > Aug 1 05:52:08 zeus kernel: [] ? xen_safe_halt+0xc/0x20 > Aug 1 05:52:08 zeus kernel: [] ? default_idle+0x23/0x40 > Aug 1 05:52:08 zeus kernel: [] ? cpu_idle+0xa6/0xc0 > > > Im am using a HP DL585 G2 running openSuse 12.1. Yet the above trace appears to be from a pv-ops kernel, which 12.1 doesn't include (nor does it ship a 3.4-based kernel in the first place). Please provide complete, consistent information. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 08:11:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 08:11:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwU1E-0007ru-9L; Wed, 01 Aug 2012 08:11:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwU1C-0007ro-Rj for xen-devel@lists.xensource.com; Wed, 01 Aug 2012 08:10:59 +0000 Received: from [85.158.139.83:4927] by server-2.bemta-5.messagelabs.com id D1/98-04598-194E8105; Wed, 01 Aug 2012 08:10:57 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-4.tower-182.messagelabs.com!1343808655!26981424!1 X-Originating-IP: [94.23.245.208] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11344 invoked from network); 1 Aug 2012 08:10:55 -0000 Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208) by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Aug 2012 08:10:55 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by lnx3.fantu.it (Postfix) with ESMTP id 034FF402208 for ; Wed, 1 Aug 2012 10:10:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it Received: from lnx3.fantu.it ([127.0.0.1]) by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFjatR9ZoyLe for ; Wed, 1 Aug 2012 10:10:54 +0200 (CEST) Received: from [192.168.178.50] (host73-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: prova@fantu.it) by lnx3.fantu.it (Postfix) with ESMTPSA id 53CF440197E for ; Wed, 1 Aug 2012 10:10:54 +0200 (CEST) Message-ID: <5018E489.6080601@tiscali.it> Date: Wed, 01 Aug 2012 10:10:49 +0200 From: Fabio Fantoni User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Build error qemu upstream 1.2 with xen-unstable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: fantonifabio@tiscali.it List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2539503632737551075==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Questo è un messaggio firmato digitalmente in formato MIME. --===============2539503632737551075== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070800000102020409050900" Questo è un messaggio firmato digitalmente in formato MIME. --------------ms070800000102020409050900 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable I had tried build from source xen 4.2.0-rc1 on Wheezy with qemu-xen from = git (commit 0b22ef0f57a8910d849602bef0940edcd0553d2c) I had encounter this build error: CC i386-softmmu/hw/i386/../xen_pt.o /mnt/vm/xen/xen-unstable.hg/tools/qemu-xen-dir/hw/i386/../xen_pt.c: In=20 function =E2xen_pci_passthrough_class_init=E2: /mnt/vm/xen/xen-unstable.hg/tools/qemu-xen-dir/hw/i386/../xen_pt.c:832:13= :=20 error: assignment from incompatible pointer type [-Werror] cc1: all warnings being treated as errors make[4]: *** [hw/i386/../xen_pt.o] Error 1 make[3]: *** [subdir-i386-softmmu] Error 2 make[3]: Leaving directory=20 `/mnt/vm/xen/xen-unstable.hg/tools/qemu-xen-dir-remote' make[2]: *** [subdir-all-qemu-xen-dir] Error 2 make[2]: Leaving directory `/mnt/vm/xen/xen-unstable.hg/tools' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/mnt/vm/xen/xen-unstable.hg/tools' make: *** [install-tools] Error 2 --------------ms070800000102020409050900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Firma crittografica S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV 10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2 YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8 h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1 kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8 oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+ qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1 XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEyMDgwMTA4MTA0OVowIwYJKoZIhvcNAQkEMRYEFGB4ev772+sBGsXDAWtAdTy/ IYTFMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAq8EWJPFrVG2WaWmajsdeFr3h bCm4gJVHEYzm+17pzpW4l9sS8CWwyooopxlyj6c5s129sQVUQ8PcRCutkNIf5/i7u1xbJ4MV v0ypDyty03loca+ZXZLyyB+vnXPHrb1IvUviSkPpdOLeKOP3di23xiJIzgG5BZzKnI7vYarX EDCOx1xYHOwynwj/UvVkcODtQWp8E/aUw/HJvUgp18jKk2PV65n273dbqmkw/gYUFRQ2RXv9 XI2LocrN2GDcH1mkInEPgt0PLUewoaNxIo7MwAHNwhJESG8MoFZ0uFDdclPOhsLQgEUBes5l QiK66pZQrnCwiVVZeq2oDeKuGJeDiAAAAAAAAA== --------------ms070800000102020409050900-- --===============2539503632737551075== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2539503632737551075==-- From xen-devel-bounces@lists.xen.org Wed Aug 01 08:11:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 08:11:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwU1E-0007ru-9L; Wed, 01 Aug 2012 08:11:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwU1C-0007ro-Rj for xen-devel@lists.xensource.com; Wed, 01 Aug 2012 08:10:59 +0000 Received: from [85.158.139.83:4927] by server-2.bemta-5.messagelabs.com id D1/98-04598-194E8105; Wed, 01 Aug 2012 08:10:57 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-4.tower-182.messagelabs.com!1343808655!26981424!1 X-Originating-IP: [94.23.245.208] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11344 invoked from network); 1 Aug 2012 08:10:55 -0000 Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208) by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Aug 2012 08:10:55 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by lnx3.fantu.it (Postfix) with ESMTP id 034FF402208 for ; Wed, 1 Aug 2012 10:10:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it Received: from lnx3.fantu.it ([127.0.0.1]) by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFjatR9ZoyLe for ; Wed, 1 Aug 2012 10:10:54 +0200 (CEST) Received: from [192.168.178.50] (host73-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: prova@fantu.it) by lnx3.fantu.it (Postfix) with ESMTPSA id 53CF440197E for ; Wed, 1 Aug 2012 10:10:54 +0200 (CEST) Message-ID: <5018E489.6080601@tiscali.it> Date: Wed, 01 Aug 2012 10:10:49 +0200 From: Fabio Fantoni User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Build error qemu upstream 1.2 with xen-unstable X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: fantonifabio@tiscali.it List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2539503632737551075==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Questo è un messaggio firmato digitalmente in formato MIME. --===============2539503632737551075== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070800000102020409050900" Questo è un messaggio firmato digitalmente in formato MIME. --------------ms070800000102020409050900 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable I had tried build from source xen 4.2.0-rc1 on Wheezy with qemu-xen from = git (commit 0b22ef0f57a8910d849602bef0940edcd0553d2c) I had encounter this build error: CC i386-softmmu/hw/i386/../xen_pt.o /mnt/vm/xen/xen-unstable.hg/tools/qemu-xen-dir/hw/i386/../xen_pt.c: In=20 function =E2xen_pci_passthrough_class_init=E2: /mnt/vm/xen/xen-unstable.hg/tools/qemu-xen-dir/hw/i386/../xen_pt.c:832:13= :=20 error: assignment from incompatible pointer type [-Werror] cc1: all warnings being treated as errors make[4]: *** [hw/i386/../xen_pt.o] Error 1 make[3]: *** [subdir-i386-softmmu] Error 2 make[3]: Leaving directory=20 `/mnt/vm/xen/xen-unstable.hg/tools/qemu-xen-dir-remote' make[2]: *** [subdir-all-qemu-xen-dir] Error 2 make[2]: Leaving directory `/mnt/vm/xen/xen-unstable.hg/tools' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/mnt/vm/xen/xen-unstable.hg/tools' make: *** [install-tools] Error 2 --------------ms070800000102020409050900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Firma crittografica S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV 10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2 YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8 h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1 kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8 oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+ qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1 XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEyMDgwMTA4MTA0OVowIwYJKoZIhvcNAQkEMRYEFGB4ev772+sBGsXDAWtAdTy/ IYTFMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAq8EWJPFrVG2WaWmajsdeFr3h bCm4gJVHEYzm+17pzpW4l9sS8CWwyooopxlyj6c5s129sQVUQ8PcRCutkNIf5/i7u1xbJ4MV v0ypDyty03loca+ZXZLyyB+vnXPHrb1IvUviSkPpdOLeKOP3di23xiJIzgG5BZzKnI7vYarX EDCOx1xYHOwynwj/UvVkcODtQWp8E/aUw/HJvUgp18jKk2PV65n273dbqmkw/gYUFRQ2RXv9 XI2LocrN2GDcH1mkInEPgt0PLUewoaNxIo7MwAHNwhJESG8MoFZ0uFDdclPOhsLQgEUBes5l QiK66pZQrnCwiVVZeq2oDeKuGJeDiAAAAAAAAA== --------------ms070800000102020409050900-- --===============2539503632737551075== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2539503632737551075==-- From xen-devel-bounces@lists.xen.org Wed Aug 01 08:22:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 08: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 1SwUBU-00084E-QL; Wed, 01 Aug 2012 08:21:36 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwUBT-000849-KC for xen-devel@lists.xen.org; Wed, 01 Aug 2012 08:21:35 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1343809283!10923935!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDc2Mjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7345 invoked from network); 1 Aug 2012 08:21:24 -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 Aug 2012 08:21:24 -0000 X-IronPort-AV: E=Sophos;i="4.77,691,1336348800"; d="scan'208";a="13796740" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Aug 2012 08:21:23 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Aug 2012 09:21:23 +0100 Message-ID: <1343809281.27221.14.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Tamas Lengyel Date: Wed, 1 Aug 2012 09:21:21 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] libxl config datastructures X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; 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-08-01 at 04:16 +0100, Tamas Lengyel wrote: > Dear libxl developers, > currently there is no way to automatically parse a config file into > the libxl_domain_config datastructure and therefore using any libxl_* > function that requires that datastructure as an input is unusable. The > only implementation that creates that structure is in xl_cmdimpl.c in > the private function parse_config_data. As I see, it relies on the > XLU_Config structure to create the libxl_domain_config structure. It > is very impractical to replicate that code for third party tools just > to be able to use for example libxl_domain_restore. There is a deliberate split in functionality here, which is part of the design of libxl. libxl is a library which can be used to implement a toolstack. It is not in and of itself a toolstack. I often say that it implements the common "bottom third" of a toolstack. xl is an actual toolstack which uses libxl and aims for, among other things, xm compatibility which implies the ability to parse xm style configuration files (and a similar command line syntax, etc). The parsing of xl/xm style configuration files is specific to the toolstack and therefore belongs in xl. It is incorrect to say that "libxl_* function that requires that datastructure as an input is unusable", it is obviously entirely possible to fill in this data structure without reference to an xm/xl style configuration file. If you are writing your own toolstack then it is expected that you will have your own configuration format and will parse that instead, there is certainly no general requirement that all toolstack use xm/xl style configuration files. For example The libxl backend for libvirt takes libvirt configuration and uses that to drive libxl in order to implement the required functionality and we expect that in the future the xapi toolstack will similarly use settings in its database to drive libxl. Now in actual fact the actual parser is in the libxlu (utils) library. This is because although the configuration file format is particular to xm/xl we acknowledge that some of the functionality of xl, such the ability to parse simple key=value configuration files or xl disk configuration specifications, might be useful to other toolstacks. > My requests is either: It would be useful if you would explain what you are actually trying to achieve here. Are you writing your own toolstack which strives for xm compatibility? Or are you perhaps trying to add functionality to libxl which actual belongs in xl? If you explain what you are doing then we can try and figure out how best to move forward. > * Create a publicly accessible function in libxl.h that parses a > file/char* to libxl_domain_config structure (essentially > making parse_config_data public). > * Or just use XLU_Config everywhere. I'm not entirely sure why > there is a need to have two separate formats and the whole > translation in-between. I don't think either of these would be correct and in keeping with the design decisions which we have made for libxl/xl. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 08:22:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 08: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 1SwUBU-00084E-QL; Wed, 01 Aug 2012 08:21:36 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwUBT-000849-KC for xen-devel@lists.xen.org; Wed, 01 Aug 2012 08:21:35 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1343809283!10923935!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDc2Mjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7345 invoked from network); 1 Aug 2012 08:21:24 -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 Aug 2012 08:21:24 -0000 X-IronPort-AV: E=Sophos;i="4.77,691,1336348800"; d="scan'208";a="13796740" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Aug 2012 08:21:23 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Aug 2012 09:21:23 +0100 Message-ID: <1343809281.27221.14.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Tamas Lengyel Date: Wed, 1 Aug 2012 09:21:21 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] libxl config datastructures X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; 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-08-01 at 04:16 +0100, Tamas Lengyel wrote: > Dear libxl developers, > currently there is no way to automatically parse a config file into > the libxl_domain_config datastructure and therefore using any libxl_* > function that requires that datastructure as an input is unusable. The > only implementation that creates that structure is in xl_cmdimpl.c in > the private function parse_config_data. As I see, it relies on the > XLU_Config structure to create the libxl_domain_config structure. It > is very impractical to replicate that code for third party tools just > to be able to use for example libxl_domain_restore. There is a deliberate split in functionality here, which is part of the design of libxl. libxl is a library which can be used to implement a toolstack. It is not in and of itself a toolstack. I often say that it implements the common "bottom third" of a toolstack. xl is an actual toolstack which uses libxl and aims for, among other things, xm compatibility which implies the ability to parse xm style configuration files (and a similar command line syntax, etc). The parsing of xl/xm style configuration files is specific to the toolstack and therefore belongs in xl. It is incorrect to say that "libxl_* function that requires that datastructure as an input is unusable", it is obviously entirely possible to fill in this data structure without reference to an xm/xl style configuration file. If you are writing your own toolstack then it is expected that you will have your own configuration format and will parse that instead, there is certainly no general requirement that all toolstack use xm/xl style configuration files. For example The libxl backend for libvirt takes libvirt configuration and uses that to drive libxl in order to implement the required functionality and we expect that in the future the xapi toolstack will similarly use settings in its database to drive libxl. Now in actual fact the actual parser is in the libxlu (utils) library. This is because although the configuration file format is particular to xm/xl we acknowledge that some of the functionality of xl, such the ability to parse simple key=value configuration files or xl disk configuration specifications, might be useful to other toolstacks. > My requests is either: It would be useful if you would explain what you are actually trying to achieve here. Are you writing your own toolstack which strives for xm compatibility? Or are you perhaps trying to add functionality to libxl which actual belongs in xl? If you explain what you are doing then we can try and figure out how best to move forward. > * Create a publicly accessible function in libxl.h that parses a > file/char* to libxl_domain_config structure (essentially > making parse_config_data public). > * Or just use XLU_Config everywhere. I'm not entirely sure why > there is a need to have two separate formats and the whole > translation in-between. I don't think either of these would be correct and in keeping with the design decisions which we have made for libxl/xl. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 08:28:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 08:28:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwUH7-0008Ct-JF; Wed, 01 Aug 2012 08:27:25 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwUH5-0008Cn-J5 for xen-devel@lists.xen.org; Wed, 01 Aug 2012 08:27:23 +0000 Received: from [85.158.143.99:56351] by server-3.bemta-4.messagelabs.com id EC/1E-01511-A68E8105; Wed, 01 Aug 2012 08:27:22 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-13.tower-216.messagelabs.com!1343809641!28799224!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0Njg3OTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 764 invoked from network); 1 Aug 2012 08:27:22 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Aug 2012 08:27:22 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 9C45A278A; Wed, 1 Aug 2012 11:27:20 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 70F7A2005D; Wed, 1 Aug 2012 11:27:20 +0300 (EEST) Date: Wed, 1 Aug 2012 11:27:20 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: lmw@satx.rr.com Message-ID: <20120801082720.GC19851@reaktio.net> References: <20120731230841.M5H9R.154709.root@cdptpa-web20-z02> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120731230841.M5H9R.154709.root@cdptpa-web20-z02> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] serial="pty" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Jul 31, 2012 at 11:08:41PM +0000, lmw@satx.rr.com wrote: > When adding the keyword serial="pty" to a xen cfg file, I am able to open /dev/ttyS0 in my dom-U linux kernel environment and send serial data to a /dev/pts/x port in my dom-0 linux environment. If I happen to have have multiple dom-U's configured this way, what is the best way to determine how these ports will be mapped so I will know which /dev/pts port belongs to which dom-U's /dev/ttyS0 port? > You can see that info at least from xenstore, dunno if there are other ways.. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 08:28:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 08:28:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwUH7-0008Ct-JF; Wed, 01 Aug 2012 08:27:25 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwUH5-0008Cn-J5 for xen-devel@lists.xen.org; Wed, 01 Aug 2012 08:27:23 +0000 Received: from [85.158.143.99:56351] by server-3.bemta-4.messagelabs.com id EC/1E-01511-A68E8105; Wed, 01 Aug 2012 08:27:22 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-13.tower-216.messagelabs.com!1343809641!28799224!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0Njg3OTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 764 invoked from network); 1 Aug 2012 08:27:22 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Aug 2012 08:27:22 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 9C45A278A; Wed, 1 Aug 2012 11:27:20 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 70F7A2005D; Wed, 1 Aug 2012 11:27:20 +0300 (EEST) Date: Wed, 1 Aug 2012 11:27:20 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: lmw@satx.rr.com Message-ID: <20120801082720.GC19851@reaktio.net> References: <20120731230841.M5H9R.154709.root@cdptpa-web20-z02> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120731230841.M5H9R.154709.root@cdptpa-web20-z02> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] serial="pty" X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Jul 31, 2012 at 11:08:41PM +0000, lmw@satx.rr.com wrote: > When adding the keyword serial="pty" to a xen cfg file, I am able to open /dev/ttyS0 in my dom-U linux kernel environment and send serial data to a /dev/pts/x port in my dom-0 linux environment. If I happen to have have multiple dom-U's configured this way, what is the best way to determine how these ports will be mapped so I will know which /dev/pts port belongs to which dom-U's /dev/ttyS0 port? > You can see that info at least from xenstore, dunno if there are other ways.. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 08:35:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 08:35:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwUOd-0008TA-Fn; Wed, 01 Aug 2012 08:35:11 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwUOd-0008T5-0q for xen-devel@lists.xensource.com; Wed, 01 Aug 2012 08:35:11 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1343810102!4930616!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDc2Mjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2525 invoked from network); 1 Aug 2012 08:35:02 -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; 1 Aug 2012 08:35:02 -0000 X-IronPort-AV: E=Sophos;i="4.77,691,1336348800"; d="scan'208";a="13796976" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Aug 2012 08:34:31 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Aug 2012 09:34:31 +0100 Message-ID: <1343810069.27221.16.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "fantonifabio@tiscali.it" Date: Wed, 1 Aug 2012 09:34:29 +0100 In-Reply-To: <5018E489.6080601@tiscali.it> References: <5018E489.6080601@tiscali.it> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Anthony Perard , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] Build error qemu upstream 1.2 with 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="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gV2VkLCAyMDEyLTA4LTAxIGF0IDA5OjEwICswMTAwLCBGYWJpbyBGYW50b25pIHdyb3RlOgo+ IEkgaGFkIHRyaWVkIGJ1aWxkIGZyb20gc291cmNlIHhlbiA0LjIuMC1yYzEgb24gV2hlZXp5IHdp dGggcWVtdS14ZW4gZnJvbSAKPiBnaXQgKGNvbW1pdCAwYjIyZWYwZjU3YTg5MTBkODQ5NjAyYmVm MDk0MGVkY2QwNTUzZDJjKQo+IEkgaGFkIGVuY291bnRlciB0aGlzIGJ1aWxkIGVycm9yOgo+ICAg IENDICAgIGkzODYtc29mdG1tdS9ody9pMzg2Ly4uL3hlbl9wdC5vCj4gL21udC92bS94ZW4veGVu LXVuc3RhYmxlLmhnL3Rvb2xzL3FlbXUteGVuLWRpci9ody9pMzg2Ly4uL3hlbl9wdC5jOiBJbiAK PiBmdW5jdGlvbiDDonhlbl9wY2lfcGFzc3Rocm91Z2hfY2xhc3NfaW5pdMOiOgo+IC9tbnQvdm0v eGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9xZW11LXhlbi1kaXIvaHcvaTM4Ni8uLi94ZW5fcHQu Yzo4MzI6MTM6IAo+IGVycm9yOiBhc3NpZ25tZW50IGZyb20gaW5jb21wYXRpYmxlIHBvaW50ZXIg dHlwZSBbLVdlcnJvcl0KPiBjYzE6IGFsbCB3YXJuaW5ncyBiZWluZyB0cmVhdGVkIGFzIGVycm9y cwoKVGhpcyBpcyB0aGUgc2FtZSBhcyB0aGUgYnVpbGRib3QgZmFpbHVyZSByZXBvcnQgb24gcWVt dS1kZXZlbCB5ZXN0ZXJkYXkKKDwyMDEyMDczMTA1MDY1OC41RTIxNUJGRENAYnVpbGRib3QuYjEt c3lzdGVtcy5kZT4pLiBJIHByZXN1bWUgQW50aG9ueQooQ0NkKSBpcyBhd2FyZSwgYnV0IGhlJ3Mg anVzdCBnb25lIG9uIGhvbGlkYXkgc28gQ0NpbmcgU3RlZmFubyB0b28uCgo+IG1ha2VbNF06ICoq KiBbaHcvaTM4Ni8uLi94ZW5fcHQub10gRXJyb3IgMQo+IG1ha2VbM106ICoqKiBbc3ViZGlyLWkz ODYtc29mdG1tdV0gRXJyb3IgMgo+IG1ha2VbM106IExlYXZpbmcgZGlyZWN0b3J5IAo+IGAvbW50 L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvcWVtdS14ZW4tZGlyLXJlbW90ZScKPiBtYWtl WzJdOiAqKiogW3N1YmRpci1hbGwtcWVtdS14ZW4tZGlyXSBFcnJvciAyCj4gbWFrZVsyXTogTGVh dmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scycKPiBtYWtl WzFdOiAqKiogW3N1YmRpcnMtaW5zdGFsbF0gRXJyb3IgMgo+IG1ha2VbMV06IExlYXZpbmcgZGly ZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMnCj4gbWFrZTogKioqIFtp bnN0YWxsLXRvb2xzXSBFcnJvciAyCj4gCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz Lnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Wed Aug 01 08:35:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 08:35:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwUOd-0008TA-Fn; Wed, 01 Aug 2012 08:35:11 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwUOd-0008T5-0q for xen-devel@lists.xensource.com; Wed, 01 Aug 2012 08:35:11 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1343810102!4930616!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDc2Mjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2525 invoked from network); 1 Aug 2012 08:35:02 -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; 1 Aug 2012 08:35:02 -0000 X-IronPort-AV: E=Sophos;i="4.77,691,1336348800"; d="scan'208";a="13796976" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Aug 2012 08:34:31 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Aug 2012 09:34:31 +0100 Message-ID: <1343810069.27221.16.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "fantonifabio@tiscali.it" Date: Wed, 1 Aug 2012 09:34:29 +0100 In-Reply-To: <5018E489.6080601@tiscali.it> References: <5018E489.6080601@tiscali.it> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Anthony Perard , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] Build error qemu upstream 1.2 with 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="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gV2VkLCAyMDEyLTA4LTAxIGF0IDA5OjEwICswMTAwLCBGYWJpbyBGYW50b25pIHdyb3RlOgo+ IEkgaGFkIHRyaWVkIGJ1aWxkIGZyb20gc291cmNlIHhlbiA0LjIuMC1yYzEgb24gV2hlZXp5IHdp dGggcWVtdS14ZW4gZnJvbSAKPiBnaXQgKGNvbW1pdCAwYjIyZWYwZjU3YTg5MTBkODQ5NjAyYmVm MDk0MGVkY2QwNTUzZDJjKQo+IEkgaGFkIGVuY291bnRlciB0aGlzIGJ1aWxkIGVycm9yOgo+ICAg IENDICAgIGkzODYtc29mdG1tdS9ody9pMzg2Ly4uL3hlbl9wdC5vCj4gL21udC92bS94ZW4veGVu LXVuc3RhYmxlLmhnL3Rvb2xzL3FlbXUteGVuLWRpci9ody9pMzg2Ly4uL3hlbl9wdC5jOiBJbiAK PiBmdW5jdGlvbiDDonhlbl9wY2lfcGFzc3Rocm91Z2hfY2xhc3NfaW5pdMOiOgo+IC9tbnQvdm0v eGVuL3hlbi11bnN0YWJsZS5oZy90b29scy9xZW11LXhlbi1kaXIvaHcvaTM4Ni8uLi94ZW5fcHQu Yzo4MzI6MTM6IAo+IGVycm9yOiBhc3NpZ25tZW50IGZyb20gaW5jb21wYXRpYmxlIHBvaW50ZXIg dHlwZSBbLVdlcnJvcl0KPiBjYzE6IGFsbCB3YXJuaW5ncyBiZWluZyB0cmVhdGVkIGFzIGVycm9y cwoKVGhpcyBpcyB0aGUgc2FtZSBhcyB0aGUgYnVpbGRib3QgZmFpbHVyZSByZXBvcnQgb24gcWVt dS1kZXZlbCB5ZXN0ZXJkYXkKKDwyMDEyMDczMTA1MDY1OC41RTIxNUJGRENAYnVpbGRib3QuYjEt c3lzdGVtcy5kZT4pLiBJIHByZXN1bWUgQW50aG9ueQooQ0NkKSBpcyBhd2FyZSwgYnV0IGhlJ3Mg anVzdCBnb25lIG9uIGhvbGlkYXkgc28gQ0NpbmcgU3RlZmFubyB0b28uCgo+IG1ha2VbNF06ICoq KiBbaHcvaTM4Ni8uLi94ZW5fcHQub10gRXJyb3IgMQo+IG1ha2VbM106ICoqKiBbc3ViZGlyLWkz ODYtc29mdG1tdV0gRXJyb3IgMgo+IG1ha2VbM106IExlYXZpbmcgZGlyZWN0b3J5IAo+IGAvbW50 L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMvcWVtdS14ZW4tZGlyLXJlbW90ZScKPiBtYWtl WzJdOiAqKiogW3N1YmRpci1hbGwtcWVtdS14ZW4tZGlyXSBFcnJvciAyCj4gbWFrZVsyXTogTGVh dmluZyBkaXJlY3RvcnkgYC9tbnQvdm0veGVuL3hlbi11bnN0YWJsZS5oZy90b29scycKPiBtYWtl WzFdOiAqKiogW3N1YmRpcnMtaW5zdGFsbF0gRXJyb3IgMgo+IG1ha2VbMV06IExlYXZpbmcgZGly ZWN0b3J5IGAvbW50L3ZtL3hlbi94ZW4tdW5zdGFibGUuaGcvdG9vbHMnCj4gbWFrZTogKioqIFtp bnN0YWxsLXRvb2xzXSBFcnJvciAyCj4gCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz Lnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Wed Aug 01 08:36:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 08:36:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwUPO-0008VM-Ta; Wed, 01 Aug 2012 08: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 1SwUPN-0008V9-CZ for xen-devel@lists.xen.org; Wed, 01 Aug 2012 08:35:57 +0000 Received: from [85.158.143.35:36968] by server-1.bemta-4.messagelabs.com id F2/AA-24392-C6AE8105; Wed, 01 Aug 2012 08:35:56 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1343810151!12899808!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDc2Mjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15380 invoked from network); 1 Aug 2012 08:35:52 -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; 1 Aug 2012 08:35:52 -0000 X-IronPort-AV: E=Sophos;i="4.77,691,1336348800"; d="scan'208";a="13796996" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Aug 2012 08:35:51 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Aug 2012 09:35:51 +0100 Message-ID: <1343810149.27221.18.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= Date: Wed, 1 Aug 2012 09:35:49 +0100 In-Reply-To: <20120801082720.GC19851@reaktio.net> References: <20120731230841.M5H9R.154709.root@cdptpa-web20-z02> <20120801082720.GC19851@reaktio.net> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "lmw@satx.rr.com" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] serial="pty" X-BeenThere: xen-devel@lists.xen.org X-Mailman-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 T24gV2VkLCAyMDEyLTA4LTAxIGF0IDA5OjI3ICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90 ZToKPiBPbiBUdWUsIEp1bCAzMSwgMjAxMiBhdCAxMTowODo0MVBNICswMDAwLCBsbXdAc2F0eC5y ci5jb20gd3JvdGU6Cj4gPiBXaGVuIGFkZGluZyB0aGUga2V5d29yZCBzZXJpYWw9InB0eSIgdG8g YSB4ZW4gY2ZnIGZpbGUsIEkgYW0gYWJsZSB0byBvcGVuIC9kZXYvdHR5UzAgaW4gbXkgZG9tLVUg bGludXgga2VybmVsIGVudmlyb25tZW50IGFuZCBzZW5kIHNlcmlhbCBkYXRhIHRvIGEgL2Rldi9w dHMveCBwb3J0IGluIG15IGRvbS0wIGxpbnV4IGVudmlyb25tZW50LiAgSWYgSSBoYXBwZW4gdG8g aGF2ZSBoYXZlIG11bHRpcGxlIGRvbS1VJ3MgY29uZmlndXJlZCB0aGlzIHdheSwgd2hhdCBpcyB0 aGUgYmVzdCB3YXkgdG8gZGV0ZXJtaW5lIGhvdyB0aGVzZSBwb3J0cyB3aWxsIGJlIG1hcHBlZCBz byBJIHdpbGwga25vdyB3aGljaCAvZGV2L3B0cyBwb3J0IGJlbG9uZ3MgdG8gd2hpY2ggZG9tLVUn cyAvZGV2L3R0eVMwIHBvcnQ/Cj4gPiAKPiAKPiBZb3UgY2FuIHNlZSB0aGF0IGluZm8gYXQgbGVh c3QgZnJvbSB4ZW5zdG9yZSwgZHVubm8gaWYgdGhlcmUgYXJlIG90aGVyIHdheXMuLgoKSWYgeW91 IGFyZSB1c2luZyB4bCB0aGUgInhsIGNvbnNvbGUgPGRvbT4iIHdpbGwgZ2V0IHlvdSB0aGUgc2Vy aWFsCmNvbnNvbGUgYnkgZGVmYXVsdCAodXNlIC10IG9wdGlvbiB0byBmb3JjZSkuIEkgZG9uJ3Qg a25vdyBpZiAieG0KY29uc29sZSIgaGFkIHRoZSBzYW1lIGJlaGF2aW91ci4KCklhbi4KCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl bi1kZXZlbAo= From xen-devel-bounces@lists.xen.org Wed Aug 01 08:36:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 08:36:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwUPO-0008VM-Ta; Wed, 01 Aug 2012 08: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 1SwUPN-0008V9-CZ for xen-devel@lists.xen.org; Wed, 01 Aug 2012 08:35:57 +0000 Received: from [85.158.143.35:36968] by server-1.bemta-4.messagelabs.com id F2/AA-24392-C6AE8105; Wed, 01 Aug 2012 08:35:56 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1343810151!12899808!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDc2Mjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15380 invoked from network); 1 Aug 2012 08:35:52 -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; 1 Aug 2012 08:35:52 -0000 X-IronPort-AV: E=Sophos;i="4.77,691,1336348800"; d="scan'208";a="13796996" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Aug 2012 08:35:51 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 1 Aug 2012 09:35:51 +0100 Message-ID: <1343810149.27221.18.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= Date: Wed, 1 Aug 2012 09:35:49 +0100 In-Reply-To: <20120801082720.GC19851@reaktio.net> References: <20120731230841.M5H9R.154709.root@cdptpa-web20-z02> <20120801082720.GC19851@reaktio.net> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "lmw@satx.rr.com" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] serial="pty" X-BeenThere: xen-devel@lists.xen.org X-Mailman-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 T24gV2VkLCAyMDEyLTA4LTAxIGF0IDA5OjI3ICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90 ZToKPiBPbiBUdWUsIEp1bCAzMSwgMjAxMiBhdCAxMTowODo0MVBNICswMDAwLCBsbXdAc2F0eC5y ci5jb20gd3JvdGU6Cj4gPiBXaGVuIGFkZGluZyB0aGUga2V5d29yZCBzZXJpYWw9InB0eSIgdG8g YSB4ZW4gY2ZnIGZpbGUsIEkgYW0gYWJsZSB0byBvcGVuIC9kZXYvdHR5UzAgaW4gbXkgZG9tLVUg bGludXgga2VybmVsIGVudmlyb25tZW50IGFuZCBzZW5kIHNlcmlhbCBkYXRhIHRvIGEgL2Rldi9w dHMveCBwb3J0IGluIG15IGRvbS0wIGxpbnV4IGVudmlyb25tZW50LiAgSWYgSSBoYXBwZW4gdG8g aGF2ZSBoYXZlIG11bHRpcGxlIGRvbS1VJ3MgY29uZmlndXJlZCB0aGlzIHdheSwgd2hhdCBpcyB0 aGUgYmVzdCB3YXkgdG8gZGV0ZXJtaW5lIGhvdyB0aGVzZSBwb3J0cyB3aWxsIGJlIG1hcHBlZCBz byBJIHdpbGwga25vdyB3aGljaCAvZGV2L3B0cyBwb3J0IGJlbG9uZ3MgdG8gd2hpY2ggZG9tLVUn cyAvZGV2L3R0eVMwIHBvcnQ/Cj4gPiAKPiAKPiBZb3UgY2FuIHNlZSB0aGF0IGluZm8gYXQgbGVh c3QgZnJvbSB4ZW5zdG9yZSwgZHVubm8gaWYgdGhlcmUgYXJlIG90aGVyIHdheXMuLgoKSWYgeW91 IGFyZSB1c2luZyB4bCB0aGUgInhsIGNvbnNvbGUgPGRvbT4iIHdpbGwgZ2V0IHlvdSB0aGUgc2Vy aWFsCmNvbnNvbGUgYnkgZGVmYXVsdCAodXNlIC10IG9wdGlvbiB0byBmb3JjZSkuIEkgZG9uJ3Qg a25vdyBpZiAieG0KY29uc29sZSIgaGFkIHRoZSBzYW1lIGJlaGF2aW91ci4KCklhbi4KCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl bi1kZXZlbAo= From xen-devel-bounces@lists.xen.org Wed Aug 01 09:15:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 09:15:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwV0p-0000X4-50; Wed, 01 Aug 2012 09:14:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwV0o-0000Wz-0y for xen-devel@lists.xensource.com; Wed, 01 Aug 2012 09:14:38 +0000 Received: from [85.158.143.35:41211] by server-3.bemta-4.messagelabs.com id 40/D2-01511-D73F8105; Wed, 01 Aug 2012 09:14:37 +0000 X-Env-Sender: wdauchy@gmail.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1343812474!5423133!1 X-Originating-IP: [209.85.160.43] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18334 invoked from network); 1 Aug 2012 09:14:36 -0000 Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com) (209.85.160.43) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Aug 2012 09:14:36 -0000 Received: by pbcwz7 with SMTP id wz7so943824pbc.30 for ; Wed, 01 Aug 2012 02:14: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:from:date:message-id:subject:to :cc:content-type; bh=10SgRzKCMoeFLEld/mZTgYLNznTiWcl23IrkjnjozK0=; b=BIUeL8dpfYN92gqYfh0x3g7VohF0FXrWCxP6yn19IUZv40M/c4Y2iaUfswba5zSSLS BNiHHsDvOt2av2GQ1eeSOMoX9fnIGiR061rM7F+DLnDuAZn4Y1TX6wVeWC3RJ59ooutj FfvYPyJuBWmCz6r3Jb3qQNXcWBDNylhx/7UCnLE/EPIV0sbAPDcGqRtXFuIvhRUvV9ip PnFKJOQfBmgtbJ1v2xw+T/VvVwySfDbXqlRQyCxrkMJEqxZ+1lAH5yS4tH4dgJOLu9pN e1W+oCzet1E2PNvt76IL3dHxX0fH7GAkl3dcdD0gjc51xn1BvmVwbnD6wKwD/DLb1Cw6 D1dA== Received: by 10.68.222.9 with SMTP id qi9mr32544237pbc.164.1343812474198; Wed, 01 Aug 2012 02:14:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.135.229 with HTTP; Wed, 1 Aug 2012 02:14:13 -0700 (PDT) In-Reply-To: <20120731230830.GA32698@phenom.dumpdata.com> References: <20120731230830.GA32698@phenom.dumpdata.com> From: William Dauchy Date: Wed, 1 Aug 2012 11:14:13 +0200 Message-ID: To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] kobject (null) without dirent 3.x domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Aug 1, 2012 at 1:08 AM, Konrad Rzeszutek Wilk wrote: > Do you see this with v3.5? Thanks for your answer. Sorry, in fact I found the issue. It was a race in my api script between hotplug cpu and the start of the vm. Regards, -- William _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 09:15:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 09:15:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwV0p-0000X4-50; Wed, 01 Aug 2012 09:14:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwV0o-0000Wz-0y for xen-devel@lists.xensource.com; Wed, 01 Aug 2012 09:14:38 +0000 Received: from [85.158.143.35:41211] by server-3.bemta-4.messagelabs.com id 40/D2-01511-D73F8105; Wed, 01 Aug 2012 09:14:37 +0000 X-Env-Sender: wdauchy@gmail.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1343812474!5423133!1 X-Originating-IP: [209.85.160.43] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18334 invoked from network); 1 Aug 2012 09:14:36 -0000 Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com) (209.85.160.43) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Aug 2012 09:14:36 -0000 Received: by pbcwz7 with SMTP id wz7so943824pbc.30 for ; Wed, 01 Aug 2012 02:14: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:from:date:message-id:subject:to :cc:content-type; bh=10SgRzKCMoeFLEld/mZTgYLNznTiWcl23IrkjnjozK0=; b=BIUeL8dpfYN92gqYfh0x3g7VohF0FXrWCxP6yn19IUZv40M/c4Y2iaUfswba5zSSLS BNiHHsDvOt2av2GQ1eeSOMoX9fnIGiR061rM7F+DLnDuAZn4Y1TX6wVeWC3RJ59ooutj FfvYPyJuBWmCz6r3Jb3qQNXcWBDNylhx/7UCnLE/EPIV0sbAPDcGqRtXFuIvhRUvV9ip PnFKJOQfBmgtbJ1v2xw+T/VvVwySfDbXqlRQyCxrkMJEqxZ+1lAH5yS4tH4dgJOLu9pN e1W+oCzet1E2PNvt76IL3dHxX0fH7GAkl3dcdD0gjc51xn1BvmVwbnD6wKwD/DLb1Cw6 D1dA== Received: by 10.68.222.9 with SMTP id qi9mr32544237pbc.164.1343812474198; Wed, 01 Aug 2012 02:14:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.135.229 with HTTP; Wed, 1 Aug 2012 02:14:13 -0700 (PDT) In-Reply-To: <20120731230830.GA32698@phenom.dumpdata.com> References: <20120731230830.GA32698@phenom.dumpdata.com> From: William Dauchy Date: Wed, 1 Aug 2012 11:14:13 +0200 Message-ID: To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] kobject (null) without dirent 3.x domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Aug 1, 2012 at 1:08 AM, Konrad Rzeszutek Wilk wrote: > Do you see this with v3.5? Thanks for your answer. Sorry, in fact I found the issue. It was a race in my api script between hotplug cpu and the start of the vm. Regards, -- William _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 09:18:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 09:18:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwV3W-0000cc-NU; Wed, 01 Aug 2012 09:17:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwV3V-0000cX-4I for xen-devel@lists.xen.org; Wed, 01 Aug 2012 09:17:25 +0000 Received: from [85.158.143.35:57923] by server-1.bemta-4.messagelabs.com id 4B/30-24392-424F8105; Wed, 01 Aug 2012 09:17:24 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1343812643!15572403!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32218 invoked from network); 1 Aug 2012 09:17:23 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-21.messagelabs.com with SMTP; 1 Aug 2012 09:17:23 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 01 Aug 2012 10:17:22 +0100 Message-Id: <5019106B0200007800091D22@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 01 Aug 2012 10:18:03 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part8FBECA5B.0__=" Subject: [Xen-devel] linux-2.6.18/x86: fix context switch on debug hypervisor after 1183:5e3c342a325e X-BeenThere: xen-devel@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. --=__Part8FBECA5B.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Looking at anything but the result field of a multicall structure after issuing the multicall is invalid - the debug hypervisor intentionally clobbers all other fields. On i386 also remove some left over debugging code. Signed-off-by: Jan Beulich --- a/arch/i386/kernel/process-xen.c +++ b/arch/i386/kernel/process-xen.c @@ -548,7 +548,7 @@ struct task_struct fastcall * __switch_t { struct thread_struct *prev =3D &prev_p->thread, *next =3D &next_p->thread; - int cpu =3D smp_processor_id(); + int cpu =3D smp_processor_id(), cr0_ts; #ifndef CONFIG_X86_NO_TSS struct tss_struct *tss =3D &per_cpu(init_tss, cpu); #endif @@ -575,9 +575,6 @@ struct task_struct fastcall * __switch_t mcl->args[0] =3D 1; mcl++; } -#if 0 /* lazy fpu sanity check */ - else BUG_ON(!(read_cr0() & 8)); -#endif =20 /* * Reload esp0. @@ -639,11 +636,14 @@ struct task_struct fastcall * __switch_t BUG_ON(pdo > _pdo + ARRAY_SIZE(_pdo)); #endif BUG_ON(mcl > _mcl + ARRAY_SIZE(_mcl)); - if (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch) + if (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch) { __get_cpu_var(xen_x86_cr0_upd) =3D X86_CR0_TS; + cr0_ts =3D 1; + } else + cr0_ts =3D 0; if (unlikely(HYPERVISOR_multicall_check(_mcl, mcl - _mcl, NULL))) BUG(); - if (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch) { + if (cr0_ts) { __get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS; xen_clear_cr0_upd(); } --- a/arch/x86_64/kernel/process-xen.c +++ b/arch/x86_64/kernel/process-xen.c @@ -486,7 +486,7 @@ __switch_to(struct task_struct *prev_p,=20 { struct thread_struct *prev =3D &prev_p->thread, *next =3D &next_p->thread; - int cpu =3D smp_processor_id(); =20 + int cpu =3D smp_processor_id(), cr0_ts; #ifndef CONFIG_X86_NO_TSS struct tss_struct *tss =3D &per_cpu(init_tss, cpu); #endif @@ -572,11 +572,14 @@ __switch_to(struct task_struct *prev_p,=20 BUG_ON(pdo > _pdo + ARRAY_SIZE(_pdo)); #endif BUG_ON(mcl > _mcl + ARRAY_SIZE(_mcl)); - if (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch) + if (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch) { __get_cpu_var(xen_x86_cr0_upd) =3D X86_CR0_TS; + cr0_ts =3D 1; + } else + cr0_ts =3D 0; if (unlikely(HYPERVISOR_multicall_check(_mcl, mcl - _mcl, NULL))) BUG(); - if (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch) { + if (cr0_ts) { __get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS; xen_clear_cr0_upd(); } --=__Part8FBECA5B.0__= Content-Type: text/plain; name="xen-x86-cr0-fix.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xen-x86-cr0-fix.patch" x86: fix context switch on debug hypervisor after 1183:5e3c342a325e=0A=0ALo= oking at anything but the result field of a multicall structure after=0Aiss= uing the multicall is invalid - the debug hypervisor intentionally=0Aclobbe= rs all other fields.=0A=0AOn i386 also remove some left over debugging = code.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- = a/arch/i386/kernel/process-xen.c=0A+++ b/arch/i386/kernel/process-xen.c=0A@= @ -548,7 +548,7 @@ struct task_struct fastcall * __switch_t=0A {=0A = struct thread_struct *prev =3D &prev_p->thread,=0A = *next =3D &next_p->thread;=0A- int cpu =3D smp_processor_id();=0A+ = int cpu =3D smp_processor_id(), cr0_ts;=0A #ifndef CONFIG_X86_NO_TSS=0A = struct tss_struct *tss =3D &per_cpu(init_tss, cpu);=0A #endif=0A@@ -575,9 = +575,6 @@ struct task_struct fastcall * __switch_t=0A mcl->args[0= ] =3D 1;=0A mcl++;=0A }=0A-#if 0 /* lazy fpu sanity = check */=0A- else BUG_ON(!(read_cr0() & 8));=0A-#endif=0A =0A = /*=0A * Reload esp0.=0A@@ -639,11 +636,14 @@ struct task_struct = fastcall * __switch_t=0A BUG_ON(pdo > _pdo + ARRAY_SIZE(_pdo));=0A = #endif=0A BUG_ON(mcl > _mcl + ARRAY_SIZE(_mcl));=0A- if = (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch)=0A+ if (_mcl->op = =3D=3D __HYPERVISOR_fpu_taskswitch) {=0A __get_cpu_var(xen_x= 86_cr0_upd) =3D X86_CR0_TS;=0A+ cr0_ts =3D 1;=0A+ } else=0A+ = cr0_ts =3D 0;=0A if (unlikely(HYPERVISOR_multicall_check(_mc= l, mcl - _mcl, NULL)))=0A BUG();=0A- if (_mcl->op = =3D=3D __HYPERVISOR_fpu_taskswitch) {=0A+ if (cr0_ts) {=0A = __get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS;=0A xen_clear_cr0_upd()= ;=0A }=0A--- a/arch/x86_64/kernel/process-xen.c=0A+++ b/arch/x86_64/kern= el/process-xen.c=0A@@ -486,7 +486,7 @@ __switch_to(struct task_struct = *prev_p, =0A {=0A struct thread_struct *prev =3D &prev_p->thread,=0A = *next =3D &next_p->thread;=0A- int cpu = =3D smp_processor_id(); =0A+ int cpu =3D smp_processor_id(), cr0_ts;=0A = #ifndef CONFIG_X86_NO_TSS=0A struct tss_struct *tss =3D &per_cpu(init_ts= s, cpu);=0A #endif=0A@@ -572,11 +572,14 @@ __switch_to(struct task_struct = *prev_p, =0A BUG_ON(pdo > _pdo + ARRAY_SIZE(_pdo));=0A #endif=0A = BUG_ON(mcl > _mcl + ARRAY_SIZE(_mcl));=0A- if (_mcl->op =3D=3D = __HYPERVISOR_fpu_taskswitch)=0A+ if (_mcl->op =3D=3D __HYPERVISOR_fp= u_taskswitch) {=0A __get_cpu_var(xen_x86_cr0_upd) =3D = X86_CR0_TS;=0A+ cr0_ts =3D 1;=0A+ } else=0A+ = cr0_ts =3D 0;=0A if (unlikely(HYPERVISOR_multicall_check(_mcl, mcl = - _mcl, NULL)))=0A BUG();=0A- if (_mcl->op =3D=3D = __HYPERVISOR_fpu_taskswitch) {=0A+ if (cr0_ts) {=0A = __get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS;=0A xen_clear_cr0_upd()= ;=0A }=0A --=__Part8FBECA5B.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 --=__Part8FBECA5B.0__=-- From xen-devel-bounces@lists.xen.org Wed Aug 01 09:18:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 09:18:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwV3W-0000cc-NU; Wed, 01 Aug 2012 09:17:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwV3V-0000cX-4I for xen-devel@lists.xen.org; Wed, 01 Aug 2012 09:17:25 +0000 Received: from [85.158.143.35:57923] by server-1.bemta-4.messagelabs.com id 4B/30-24392-424F8105; Wed, 01 Aug 2012 09:17:24 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1343812643!15572403!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32218 invoked from network); 1 Aug 2012 09:17:23 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-21.messagelabs.com with SMTP; 1 Aug 2012 09:17:23 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 01 Aug 2012 10:17:22 +0100 Message-Id: <5019106B0200007800091D22@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 01 Aug 2012 10:18:03 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part8FBECA5B.0__=" Subject: [Xen-devel] linux-2.6.18/x86: fix context switch on debug hypervisor after 1183:5e3c342a325e X-BeenThere: xen-devel@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. --=__Part8FBECA5B.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Looking at anything but the result field of a multicall structure after issuing the multicall is invalid - the debug hypervisor intentionally clobbers all other fields. On i386 also remove some left over debugging code. Signed-off-by: Jan Beulich --- a/arch/i386/kernel/process-xen.c +++ b/arch/i386/kernel/process-xen.c @@ -548,7 +548,7 @@ struct task_struct fastcall * __switch_t { struct thread_struct *prev =3D &prev_p->thread, *next =3D &next_p->thread; - int cpu =3D smp_processor_id(); + int cpu =3D smp_processor_id(), cr0_ts; #ifndef CONFIG_X86_NO_TSS struct tss_struct *tss =3D &per_cpu(init_tss, cpu); #endif @@ -575,9 +575,6 @@ struct task_struct fastcall * __switch_t mcl->args[0] =3D 1; mcl++; } -#if 0 /* lazy fpu sanity check */ - else BUG_ON(!(read_cr0() & 8)); -#endif =20 /* * Reload esp0. @@ -639,11 +636,14 @@ struct task_struct fastcall * __switch_t BUG_ON(pdo > _pdo + ARRAY_SIZE(_pdo)); #endif BUG_ON(mcl > _mcl + ARRAY_SIZE(_mcl)); - if (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch) + if (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch) { __get_cpu_var(xen_x86_cr0_upd) =3D X86_CR0_TS; + cr0_ts =3D 1; + } else + cr0_ts =3D 0; if (unlikely(HYPERVISOR_multicall_check(_mcl, mcl - _mcl, NULL))) BUG(); - if (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch) { + if (cr0_ts) { __get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS; xen_clear_cr0_upd(); } --- a/arch/x86_64/kernel/process-xen.c +++ b/arch/x86_64/kernel/process-xen.c @@ -486,7 +486,7 @@ __switch_to(struct task_struct *prev_p,=20 { struct thread_struct *prev =3D &prev_p->thread, *next =3D &next_p->thread; - int cpu =3D smp_processor_id(); =20 + int cpu =3D smp_processor_id(), cr0_ts; #ifndef CONFIG_X86_NO_TSS struct tss_struct *tss =3D &per_cpu(init_tss, cpu); #endif @@ -572,11 +572,14 @@ __switch_to(struct task_struct *prev_p,=20 BUG_ON(pdo > _pdo + ARRAY_SIZE(_pdo)); #endif BUG_ON(mcl > _mcl + ARRAY_SIZE(_mcl)); - if (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch) + if (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch) { __get_cpu_var(xen_x86_cr0_upd) =3D X86_CR0_TS; + cr0_ts =3D 1; + } else + cr0_ts =3D 0; if (unlikely(HYPERVISOR_multicall_check(_mcl, mcl - _mcl, NULL))) BUG(); - if (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch) { + if (cr0_ts) { __get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS; xen_clear_cr0_upd(); } --=__Part8FBECA5B.0__= Content-Type: text/plain; name="xen-x86-cr0-fix.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xen-x86-cr0-fix.patch" x86: fix context switch on debug hypervisor after 1183:5e3c342a325e=0A=0ALo= oking at anything but the result field of a multicall structure after=0Aiss= uing the multicall is invalid - the debug hypervisor intentionally=0Aclobbe= rs all other fields.=0A=0AOn i386 also remove some left over debugging = code.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- = a/arch/i386/kernel/process-xen.c=0A+++ b/arch/i386/kernel/process-xen.c=0A@= @ -548,7 +548,7 @@ struct task_struct fastcall * __switch_t=0A {=0A = struct thread_struct *prev =3D &prev_p->thread,=0A = *next =3D &next_p->thread;=0A- int cpu =3D smp_processor_id();=0A+ = int cpu =3D smp_processor_id(), cr0_ts;=0A #ifndef CONFIG_X86_NO_TSS=0A = struct tss_struct *tss =3D &per_cpu(init_tss, cpu);=0A #endif=0A@@ -575,9 = +575,6 @@ struct task_struct fastcall * __switch_t=0A mcl->args[0= ] =3D 1;=0A mcl++;=0A }=0A-#if 0 /* lazy fpu sanity = check */=0A- else BUG_ON(!(read_cr0() & 8));=0A-#endif=0A =0A = /*=0A * Reload esp0.=0A@@ -639,11 +636,14 @@ struct task_struct = fastcall * __switch_t=0A BUG_ON(pdo > _pdo + ARRAY_SIZE(_pdo));=0A = #endif=0A BUG_ON(mcl > _mcl + ARRAY_SIZE(_mcl));=0A- if = (_mcl->op =3D=3D __HYPERVISOR_fpu_taskswitch)=0A+ if (_mcl->op = =3D=3D __HYPERVISOR_fpu_taskswitch) {=0A __get_cpu_var(xen_x= 86_cr0_upd) =3D X86_CR0_TS;=0A+ cr0_ts =3D 1;=0A+ } else=0A+ = cr0_ts =3D 0;=0A if (unlikely(HYPERVISOR_multicall_check(_mc= l, mcl - _mcl, NULL)))=0A BUG();=0A- if (_mcl->op = =3D=3D __HYPERVISOR_fpu_taskswitch) {=0A+ if (cr0_ts) {=0A = __get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS;=0A xen_clear_cr0_upd()= ;=0A }=0A--- a/arch/x86_64/kernel/process-xen.c=0A+++ b/arch/x86_64/kern= el/process-xen.c=0A@@ -486,7 +486,7 @@ __switch_to(struct task_struct = *prev_p, =0A {=0A struct thread_struct *prev =3D &prev_p->thread,=0A = *next =3D &next_p->thread;=0A- int cpu = =3D smp_processor_id(); =0A+ int cpu =3D smp_processor_id(), cr0_ts;=0A = #ifndef CONFIG_X86_NO_TSS=0A struct tss_struct *tss =3D &per_cpu(init_ts= s, cpu);=0A #endif=0A@@ -572,11 +572,14 @@ __switch_to(struct task_struct = *prev_p, =0A BUG_ON(pdo > _pdo + ARRAY_SIZE(_pdo));=0A #endif=0A = BUG_ON(mcl > _mcl + ARRAY_SIZE(_mcl));=0A- if (_mcl->op =3D=3D = __HYPERVISOR_fpu_taskswitch)=0A+ if (_mcl->op =3D=3D __HYPERVISOR_fp= u_taskswitch) {=0A __get_cpu_var(xen_x86_cr0_upd) =3D = X86_CR0_TS;=0A+ cr0_ts =3D 1;=0A+ } else=0A+ = cr0_ts =3D 0;=0A if (unlikely(HYPERVISOR_multicall_check(_mcl, mcl = - _mcl, NULL)))=0A BUG();=0A- if (_mcl->op =3D=3D = __HYPERVISOR_fpu_taskswitch) {=0A+ if (cr0_ts) {=0A = __get_cpu_var(xen_x86_cr0) |=3D X86_CR0_TS;=0A xen_clear_cr0_upd()= ;=0A }=0A --=__Part8FBECA5B.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 --=__Part8FBECA5B.0__=-- From xen-devel-bounces@lists.xen.org Wed Aug 01 09:18:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 09:18: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 1SwV46-0000eT-4i; Wed, 01 Aug 2012 09:18:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwV44-0000eE-W8 for xen-devel@lists.xen.org; Wed, 01 Aug 2012 09:18:01 +0000 Received: from [85.158.143.35:20570] by server-2.bemta-4.messagelabs.com id B8/EA-17938-844F8105; Wed, 01 Aug 2012 09:18:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1343812679!16867356!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDc3NDk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15098 invoked from network); 1 Aug 2012 09:17:59 -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; 1 Aug 2012 09:17:59 -0000 X-IronPort-AV: E=Sophos;i="4.77,693,1336348800"; d="scan'208";a="13797858" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Aug 2012 09:17: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, 1 Aug 2012 10:17:59 +0100 Message-ID: <1343812677.27221.40.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "greg@enjellic.com" Date: Wed, 1 Aug 2012 10:17:57 +0100 In-Reply-To: <201207312141.q6VLfJje012656@wind.enjellic.com> References: <201207312141.q6VLfJje012656@wind.enjellic.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Blktap fixes and kernel 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 On Tue, 2012-07-31 at 22:41 +0100, Dr. Greg Wettstein wrote: > After becoming far more familiar with the XEN vbd infrastructure then > I had intended I was finally able to run down the problem with the > blktap2 driver which has plagued 4.1.2. Most specifically the > orphaning of the tapdisk2 driver process and after Ian's fix for that, > the hang and orphaning of a tapdisk minor which occurs when libxl > attempts to shutdown the driver process. Thanks for digging into this Greg. > In the process I updated the blktap2 kernel driver to patch cleanly > into the Linux 3.4 kernel. These fixes have been validated against > the 3.4 kernel as well as the 3.2 kernel. Just to be clear this is just a straight forward port, there's no part of the deadlock fix in here? > The first patch is one which was done by Ian for the development tree > with minor corrections for 4.1.2. I'm including it for completeness > for those who want a trouble free patch set for a 4.1.2 distribution. > This patch fixes the orphaning of the tapdisk2 driver process when xl > shuts down. This is a fairly straight backport of a patch in unstable? If you send a mail with a subject "Xen 4.1.x backport request " explaining which commit it is and CC keir@xen.org & ian.jackson@eu.citrix.com then we can see about getting this into a future 4.1.x (perhaps even 4.1.3, not sure which stage of rcs we are at there). If the backport is reasonably trivial then there is often no need to include it but since you have done so you might as well include the patch for reference. > The second patch corrects the deadlock which occurs between the > blktap2 kernel driver and the blktap2 userspace control plane. The > deadlock causes a delay in the shutdown of a XEN guest and results in > the 'orphaning' of tapdisk minor number allocations. As seems to be > typical with these types of things the fix was trivially straight > forward once I finally figured out what was going on. Thanks for this. Am I right that the important functional change here is that the xs_rm needs to come after we read the params node but before tap_ctl_destroy? Obviously removing the node before calling libxl__device_destroy_tapdisk is wrong since libxl__device_destroy_tapdisk reads from be_path! Looking at 4.2.0-rc1 I see that libxl__device_destroy removes the backend before calling libxl__device_destroy_tapdisk, so I think that a fix is needed there too. I'm less sure about the usage in libxl__initiate_device_remove. I wonder if the call to libxl__device_destroy_tapdisk there needs to move to device_hotplug_done right after the transaction which cleans up the backend back? The code which used to be in libxl__devices_destroy is now in libxl__initiate_device_remove so I expect that fixing that would be sufficient. I'd really appreciate it if you could validate whether 4.2.0-rc1 works for you or not, I suspect not. We would usually want fix the development version before considering fixes for the stable branches (even if the actual patch ends up looking totally different) otherwise we run the risk of regressions in the next version. Is there a simple command which will list the leaked tap devices? If so we can consider adding it to the leak-check phase of the automated tests (although I'm not sure how much use these make of blktap) For future reference if you intend for a patch to be applied it is best to submit it in the form described in http://wiki.xen.org/wiki/Submitting_Xen_Patches, that is one patch per email, with a changelog specific to that change and a Signed-off-by. In this sort of scenario (a patch going to 4.1 which isn't a backport) the changelog should also mention why the patch isn't a backport. > Ian for your reference the following change which you introduced to > address this issue: > > 79e3dbe4b659e78408a9eea76c51a601bd4a383a > tapdisk: respond to destroy request before tearing down the commuication channel > > Is not needed and does not provide formally correct behavior in the > presence of the two patches noted above. Is it incorrect (i.e. should be reverted) or is it just incomplete/not helpful? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 09:18:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 09:18: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 1SwV46-0000eT-4i; Wed, 01 Aug 2012 09:18:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwV44-0000eE-W8 for xen-devel@lists.xen.org; Wed, 01 Aug 2012 09:18:01 +0000 Received: from [85.158.143.35:20570] by server-2.bemta-4.messagelabs.com id B8/EA-17938-844F8105; Wed, 01 Aug 2012 09:18:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1343812679!16867356!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDc3NDk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15098 invoked from network); 1 Aug 2012 09:17:59 -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; 1 Aug 2012 09:17:59 -0000 X-IronPort-AV: E=Sophos;i="4.77,693,1336348800"; d="scan'208";a="13797858" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Aug 2012 09:17: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, 1 Aug 2012 10:17:59 +0100 Message-ID: <1343812677.27221.40.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "greg@enjellic.com" Date: Wed, 1 Aug 2012 10:17:57 +0100 In-Reply-To: <201207312141.q6VLfJje012656@wind.enjellic.com> References: <201207312141.q6VLfJje012656@wind.enjellic.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Blktap fixes and kernel 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 On Tue, 2012-07-31 at 22:41 +0100, Dr. Greg Wettstein wrote: > After becoming far more familiar with the XEN vbd infrastructure then > I had intended I was finally able to run down the problem with the > blktap2 driver which has plagued 4.1.2. Most specifically the > orphaning of the tapdisk2 driver process and after Ian's fix for that, > the hang and orphaning of a tapdisk minor which occurs when libxl > attempts to shutdown the driver process. Thanks for digging into this Greg. > In the process I updated the blktap2 kernel driver to patch cleanly > into the Linux 3.4 kernel. These fixes have been validated against > the 3.4 kernel as well as the 3.2 kernel. Just to be clear this is just a straight forward port, there's no part of the deadlock fix in here? > The first patch is one which was done by Ian for the development tree > with minor corrections for 4.1.2. I'm including it for completeness > for those who want a trouble free patch set for a 4.1.2 distribution. > This patch fixes the orphaning of the tapdisk2 driver process when xl > shuts down. This is a fairly straight backport of a patch in unstable? If you send a mail with a subject "Xen 4.1.x backport request " explaining which commit it is and CC keir@xen.org & ian.jackson@eu.citrix.com then we can see about getting this into a future 4.1.x (perhaps even 4.1.3, not sure which stage of rcs we are at there). If the backport is reasonably trivial then there is often no need to include it but since you have done so you might as well include the patch for reference. > The second patch corrects the deadlock which occurs between the > blktap2 kernel driver and the blktap2 userspace control plane. The > deadlock causes a delay in the shutdown of a XEN guest and results in > the 'orphaning' of tapdisk minor number allocations. As seems to be > typical with these types of things the fix was trivially straight > forward once I finally figured out what was going on. Thanks for this. Am I right that the important functional change here is that the xs_rm needs to come after we read the params node but before tap_ctl_destroy? Obviously removing the node before calling libxl__device_destroy_tapdisk is wrong since libxl__device_destroy_tapdisk reads from be_path! Looking at 4.2.0-rc1 I see that libxl__device_destroy removes the backend before calling libxl__device_destroy_tapdisk, so I think that a fix is needed there too. I'm less sure about the usage in libxl__initiate_device_remove. I wonder if the call to libxl__device_destroy_tapdisk there needs to move to device_hotplug_done right after the transaction which cleans up the backend back? The code which used to be in libxl__devices_destroy is now in libxl__initiate_device_remove so I expect that fixing that would be sufficient. I'd really appreciate it if you could validate whether 4.2.0-rc1 works for you or not, I suspect not. We would usually want fix the development version before considering fixes for the stable branches (even if the actual patch ends up looking totally different) otherwise we run the risk of regressions in the next version. Is there a simple command which will list the leaked tap devices? If so we can consider adding it to the leak-check phase of the automated tests (although I'm not sure how much use these make of blktap) For future reference if you intend for a patch to be applied it is best to submit it in the form described in http://wiki.xen.org/wiki/Submitting_Xen_Patches, that is one patch per email, with a changelog specific to that change and a Signed-off-by. In this sort of scenario (a patch going to 4.1 which isn't a backport) the changelog should also mention why the patch isn't a backport. > Ian for your reference the following change which you introduced to > address this issue: > > 79e3dbe4b659e78408a9eea76c51a601bd4a383a > tapdisk: respond to destroy request before tearing down the commuication channel > > Is not needed and does not provide formally correct behavior in the > presence of the two patches noted above. Is it incorrect (i.e. should be reverted) or is it just incomplete/not helpful? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Aug 01 09:18:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 09: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 1SwV47-0000eo-LE; Wed, 01 Aug 2012 09:18:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwV45-0000eF-Hk for xen-devel@lists.xen.org; Wed, 01 Aug 2012 09:18:01 +0000 Received: from [85.158.143.35:60123] by server-2.bemta-4.messagelabs.com id DE/EA-17938-844F8105; Wed, 01 Aug 2012 09:18:00 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1343812679!12910268!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20890 invoked from network); 1 Aug 2012 09:17:59 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-21.messagelabs.com with SMTP; 1 Aug 2012 09:17:59 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 01 Aug 2012 10:17:59 +0100 Message-Id: <501910900200007800091D2F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 01 Aug 2012 10:18:40 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartB485F160.0__=" Subject: [Xen-devel] [PATCH] linux-2.6.18/mm: properly frame Xen additions with CONFIG_XEN conditionals X-BeenThere: xen-devel@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. --=__PartB485F160.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline There's no need and no good reason to affect native kernels built from the same sources. Also eliminate a compiler warning triggered by various versions, and adjust some white space. Signed-off-by: Jan Beulich --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -209,14 +209,15 @@ struct vm_operations_struct { /* notification that a previously read-only page is about to = become * writable, if an error is returned it will cause a SIGBUS */ int (*page_mkwrite)(struct vm_area_struct *vma, struct page = *page); +#ifdef CONFIG_XEN /* Area-specific function for clearing the PTE at @ptep. Returns = the * original value of @ptep. */ - pte_t (*zap_pte)(struct vm_area_struct *vma,=20 + pte_t (*zap_pte)(struct vm_area_struct *vma, unsigned long addr, pte_t *ptep, int is_fullmm); =20 - /* called before close() to indicate no more pages should be = mapped */ - void (*unmap)(struct vm_area_struct *area); - + /* called before close() to indicate no more pages should be = mapped */ + void (*unmap)(struct vm_area_struct *area); +#endif #ifdef CONFIG_NUMA int (*set_policy)(struct vm_area_struct *vma, struct mempolicy = *new); struct mempolicy *(*get_policy)(struct vm_area_struct *vma, --- a/mm/memory.c +++ b/mm/memory.c @@ -409,7 +409,9 @@ struct page *vm_normal_page(struct vm_ar * and that the resulting page looks ok. */ if (unlikely(!pfn_valid(pfn))) { +#ifdef CONFIG_XEN if (!(vma->vm_flags & VM_RESERVED)) +#endif print_bad_pte(vma, pte, addr); return NULL; } @@ -665,10 +667,12 @@ static unsigned long zap_pte_range(struc page->index > details->last_index)) continue; } +#ifdef CONFIG_XEN if (unlikely(vma->vm_ops && vma->vm_ops->zap_pte)) ptent =3D vma->vm_ops->zap_pte(vma, addr, = pte, tlb->fullmm); else +#endif ptent =3D ptep_get_and_clear_full(mm, = addr, pte, tlb->fullmm= ); tlb_remove_tlb_entry(tlb, pte, addr); @@ -1425,7 +1429,7 @@ static inline int apply_to_pte_range(str spinlock_t *ptl; =20 pte =3D (mm =3D=3D &init_mm) ? - pte_alloc_kernel(pmd, addr) : + ptl =3D NULL, pte_alloc_kernel(pmd, addr) : pte_alloc_map_lock(mm, pmd, addr, &ptl); if (!pte) return -ENOMEM; --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1689,8 +1689,10 @@ static void unmap_region(struct mm_struc =20 static inline void unmap_vma(struct vm_area_struct *vma) { +#ifdef CONFIG_XEN if (unlikely(vma->vm_ops && vma->vm_ops->unmap)) vma->vm_ops->unmap(vma); +#endif } =20 /* @@ -1966,7 +1968,7 @@ EXPORT_SYMBOL(do_brk); void exit_mmap(struct mm_struct *mm) { struct mmu_gather *tlb; - struct vm_area_struct *vma_tmp, *vma =3D mm->mmap; + struct vm_area_struct *vma =3D mm->mmap; unsigned long nr_accounted =3D 0; unsigned long end; =20 @@ -1974,8 +1976,11 @@ void exit_mmap(struct mm_struct *mm) arch_exit_mmap(mm); #endif =20 - for (vma_tmp =3D mm->mmap; vma_tmp; vma_tmp =3D vma_tmp->vm_next) - unmap_vma(vma_tmp); +#ifdef CONFIG_XEN + for (; vma; vma =3D vma->vm_next) + unmap_vma(vma); + vma =3D mm->mmap; +#endif =20 lru_add_drain(); flush_cache_mm(mm); --=__PartB485F160.0__= Content-Type: text/plain; name="xen-mm-conditionals.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xen-mm-conditionals.patch" mm: properly frame Xen additions with CONFIG_XEN conditionals=0A=0AThere's = no need and no good reason to affect native kernels built from=0Athe same = sources.=0A=0AAlso eliminate a compiler warning triggered by various = versions, and=0Aadjust some white space.=0A=0ASigned-off-by: Jan Beulich = =0A=0A--- a/include/linux/mm.h=0A+++ b/include/linux/mm.= h=0A@@ -209,14 +209,15 @@ struct vm_operations_struct {=0A /* = notification that a previously read-only page is about to become=0A * = writable, if an error is returned it will cause a SIGBUS */=0A int = (*page_mkwrite)(struct vm_area_struct *vma, struct page *page);=0A+#ifdef = CONFIG_XEN=0A /* Area-specific function for clearing the PTE at @ptep. = Returns the=0A * original value of @ptep. */=0A- pte_t (*zap_pte)(st= ruct vm_area_struct *vma, =0A+ pte_t (*zap_pte)(struct vm_area_struct = *vma,=0A unsigned long addr, pte_t *ptep, int = is_fullmm);=0A =0A- /* called before close() to indicate no more = pages should be mapped */=0A- void (*unmap)(struct vm_area_struct = *area);=0A-=0A+ /* called before close() to indicate no more pages should = be mapped */=0A+ void (*unmap)(struct vm_area_struct *area);=0A+#end= if=0A #ifdef CONFIG_NUMA=0A int (*set_policy)(struct vm_area_struct = *vma, struct mempolicy *new);=0A struct mempolicy *(*get_policy)(str= uct vm_area_struct *vma,=0A--- a/mm/memory.c=0A+++ b/mm/memory.c=0A@@ = -409,7 +409,9 @@ struct page *vm_normal_page(struct vm_ar=0A * and = that the resulting page looks ok.=0A */=0A if (unlikely(!pfn_valid(pfn= ))) {=0A+#ifdef CONFIG_XEN=0A if (!(vma->vm_flags & VM_RESERVED))= =0A+#endif=0A print_bad_pte(vma, pte, addr);=0A = return NULL;=0A }=0A@@ -665,10 +667,12 @@ static unsigned long = zap_pte_range(struc=0A page->index > = details->last_index))=0A = continue;=0A }=0A+#ifdef CONFIG_XEN=0A = if (unlikely(vma->vm_ops && vma->vm_ops->zap_pte))=0A = ptent =3D vma->vm_ops->zap_pte(vma, addr, pte,=0A = tlb->fullmm);=0A else=0A+#en= dif=0A ptent =3D ptep_get_and_clear_full(mm, = addr, pte,=0A = tlb->fullmm);=0A tlb_remove_tlb_entry(tlb, pte, = addr);=0A@@ -1425,7 +1429,7 @@ static inline int apply_to_pte_range(str=0A = spinlock_t *ptl;=0A =0A pte =3D (mm =3D=3D &init_mm) ?=0A- = pte_alloc_kernel(pmd, addr) :=0A+ ptl =3D NULL, = pte_alloc_kernel(pmd, addr) :=0A pte_alloc_map_lock(mm, = pmd, addr, &ptl);=0A if (!pte)=0A return -ENOMEM;=0A--- = a/mm/mmap.c=0A+++ b/mm/mmap.c=0A@@ -1689,8 +1689,10 @@ static void = unmap_region(struct mm_struc=0A =0A static inline void unmap_vma(struct = vm_area_struct *vma)=0A {=0A+#ifdef CONFIG_XEN=0A if (unlikely(vma->v= m_ops && vma->vm_ops->unmap))=0A vma->vm_ops->unmap(vma);=0A= +#endif=0A }=0A =0A /*=0A@@ -1966,7 +1968,7 @@ EXPORT_SYMBOL(do_brk);=0A = void exit_mmap(struct mm_struct *mm)=0A {=0A struct mmu_gather = *tlb;=0A- struct vm_area_struct *vma_tmp, *vma =3D mm->mmap;=0A+ = struct vm_area_struct *vma =3D mm->mmap;=0A unsigned long nr_accounted = =3D 0;=0A unsigned long end;=0A =0A@@ -1974,8 +1976,11 @@ void = exit_mmap(struct mm_struct *mm)=0A arch_exit_mmap(mm);=0A #endif=0A = =0A- for (vma_tmp =3D mm->mmap; vma_tmp; vma_tmp =3D vma_tmp->vm_next)= =0A- unmap_vma(vma_tmp);=0A+#ifdef CONFIG_XEN=0A+ for (; = vma; vma =3D vma->vm_next)=0A+ unmap_vma(vma);=0A+ vma =3D = mm->mmap;=0A+#endif=0A =0A lru_add_drain();=0A flush_cache_mm(mm);= =0A --=__PartB485F160.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 --=__PartB485F160.0__=-- From xen-devel-bounces@lists.xen.org Wed Aug 01 09:18:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 09: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 1SwV47-0000eo-LE; Wed, 01 Aug 2012 09:18:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwV45-0000eF-Hk for xen-devel@lists.xen.org; Wed, 01 Aug 2012 09:18:01 +0000 Received: from [85.158.143.35:60123] by server-2.bemta-4.messagelabs.com id DE/EA-17938-844F8105; Wed, 01 Aug 2012 09:18:00 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1343812679!12910268!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20890 invoked from network); 1 Aug 2012 09:17:59 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-21.messagelabs.com with SMTP; 1 Aug 2012 09:17:59 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 01 Aug 2012 10:17:59 +0100 Message-Id: <501910900200007800091D2F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 01 Aug 2012 10:18:40 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartB485F160.0__=" Subject: [Xen-devel] [PATCH] linux-2.6.18/mm: properly frame Xen additions with CONFIG_XEN conditionals X-BeenThere: xen-devel@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. --=__PartB485F160.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline There's no need and no good reason to affect native kernels built from the same sources. Also eliminate a compiler warning triggered by various versions, and adjust some white space. Signed-off-by: Jan Beulich --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -209,14 +209,15 @@ struct vm_operations_struct { /* notification that a previously read-only page is about to = become * writable, if an error is returned it will cause a SIGBUS */ int (*page_mkwrite)(struct vm_area_struct *vma, struct page = *page); +#ifdef CONFIG_XEN /* Area-specific function for clearing the PTE at @ptep. Returns = the * original value of @ptep. */ - pte_t (*zap_pte)(struct vm_area_struct *vma,=20 + pte_t (*zap_pte)(struct vm_area_struct *vma, unsigned long addr, pte_t *ptep, int is_fullmm); =20 - /* called before close() to indicate no more pages should be = mapped */ - void (*unmap)(struct vm_area_struct *area); - + /* called before close() to indicate no more pages should be = mapped */ + void (*unmap)(struct vm_area_struct *area); +#endif #ifdef CONFIG_NUMA int (*set_policy)(struct vm_area_struct *vma, struct mempolicy = *new); struct mempolicy *(*get_policy)(struct vm_area_struct *vma, --- a/mm/memory.c +++ b/mm/memory.c @@ -409,7 +409,9 @@ struct page *vm_normal_page(struct vm_ar * and that the resulting page looks ok. */ if (unlikely(!pfn_valid(pfn))) { +#ifdef CONFIG_XEN if (!(vma->vm_flags & VM_RESERVED)) +#endif print_bad_pte(vma, pte, addr); return NULL; } @@ -665,10 +667,12 @@ static unsigned long zap_pte_range(struc page->index > details->last_index)) continue; } +#ifdef CONFIG_XEN if (unlikely(vma->vm_ops && vma->vm_ops->zap_pte)) ptent =3D vma->vm_ops->zap_pte(vma, addr, = pte, tlb->fullmm); else +#endif ptent =3D ptep_get_and_clear_full(mm, = addr, pte, tlb->fullmm= ); tlb_remove_tlb_entry(tlb, pte, addr); @@ -1425,7 +1429,7 @@ static inline int apply_to_pte_range(str spinlock_t *ptl; =20 pte =3D (mm =3D=3D &init_mm) ? - pte_alloc_kernel(pmd, addr) : + ptl =3D NULL, pte_alloc_kernel(pmd, addr) : pte_alloc_map_lock(mm, pmd, addr, &ptl); if (!pte) return -ENOMEM; --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1689,8 +1689,10 @@ static void unmap_region(struct mm_struc =20 static inline void unmap_vma(struct vm_area_struct *vma) { +#ifdef CONFIG_XEN if (unlikely(vma->vm_ops && vma->vm_ops->unmap)) vma->vm_ops->unmap(vma); +#endif } =20 /* @@ -1966,7 +1968,7 @@ EXPORT_SYMBOL(do_brk); void exit_mmap(struct mm_struct *mm) { struct mmu_gather *tlb; - struct vm_area_struct *vma_tmp, *vma =3D mm->mmap; + struct vm_area_struct *vma =3D mm->mmap; unsigned long nr_accounted =3D 0; unsigned long end; =20 @@ -1974,8 +1976,11 @@ void exit_mmap(struct mm_struct *mm) arch_exit_mmap(mm); #endif =20 - for (vma_tmp =3D mm->mmap; vma_tmp; vma_tmp =3D vma_tmp->vm_next) - unmap_vma(vma_tmp); +#ifdef CONFIG_XEN + for (; vma; vma =3D vma->vm_next) + unmap_vma(vma); + vma =3D mm->mmap; +#endif =20 lru_add_drain(); flush_cache_mm(mm); --=__PartB485F160.0__= Content-Type: text/plain; name="xen-mm-conditionals.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xen-mm-conditionals.patch" mm: properly frame Xen additions with CONFIG_XEN conditionals=0A=0AThere's = no need and no good reason to affect native kernels built from=0Athe same = sources.=0A=0AAlso eliminate a compiler warning triggered by various = versions, and=0Aadjust some white space.=0A=0ASigned-off-by: Jan Beulich = =0A=0A--- a/include/linux/mm.h=0A+++ b/include/linux/mm.= h=0A@@ -209,14 +209,15 @@ struct vm_operations_struct {=0A /* = notification that a previously read-only page is about to become=0A * = writable, if an error is returned it will cause a SIGBUS */=0A int = (*page_mkwrite)(struct vm_area_struct *vma, struct page *page);=0A+#ifdef = CONFIG_XEN=0A /* Area-specific function for clearing the PTE at @ptep. = Returns the=0A * original value of @ptep. */=0A- pte_t (*zap_pte)(st= ruct vm_area_struct *vma, =0A+ pte_t (*zap_pte)(struct vm_area_struct = *vma,=0A unsigned long addr, pte_t *ptep, int = is_fullmm);=0A =0A- /* called before close() to indicate no more = pages should be mapped */=0A- void (*unmap)(struct vm_area_struct = *area);=0A-=0A+ /* called before close() to indicate no more pages should = be mapped */=0A+ void (*unmap)(struct vm_area_struct *area);=0A+#end= if=0A #ifdef CONFIG_NUMA=0A int (*set_policy)(struct vm_area_struct = *vma, struct mempolicy *new);=0A struct mempolicy *(*get_policy)(str= uct vm_area_struct *vma,=0A--- a/mm/memory.c=0A+++ b/mm/memory.c=0A@@ = -409,7 +409,9 @@ struct page *vm_normal_page(struct vm_ar=0A * and = that the resulting page looks ok.=0A */=0A if (unlikely(!pfn_valid(pfn= ))) {=0A+#ifdef CONFIG_XEN=0A if (!(vma->vm_flags & VM_RESERVED))= =0A+#endif=0A print_bad_pte(vma, pte, addr);=0A = return NULL;=0A }=0A@@ -665,10 +667,12 @@ static unsigned long = zap_pte_range(struc=0A page->index > = details->last_index))=0A = continue;=0A }=0A+#ifdef CONFIG_XEN=0A = if (unlikely(vma->vm_ops && vma->vm_ops->zap_pte))=0A = ptent =3D vma->vm_ops->zap_pte(vma, addr, pte,=0A = tlb->fullmm);=0A else=0A+#en= dif=0A ptent =3D ptep_get_and_clear_full(mm, = addr, pte,=0A = tlb->fullmm);=0A tlb_remove_tlb_entry(tlb, pte, = addr);=0A@@ -1425,7 +1429,7 @@ static inline int apply_to_pte_range(str=0A = spinlock_t *ptl;=0A =0A pte =3D (mm =3D=3D &init_mm) ?=0A- = pte_alloc_kernel(pmd, addr) :=0A+ ptl =3D NULL, = pte_alloc_kernel(pmd, addr) :=0A pte_alloc_map_lock(mm, = pmd, addr, &ptl);=0A if (!pte)=0A return -ENOMEM;=0A--- = a/mm/mmap.c=0A+++ b/mm/mmap.c=0A@@ -1689,8 +1689,10 @@ static void = unmap_region(struct mm_struc=0A =0A static inline void unmap_vma(struct = vm_area_struct *vma)=0A {=0A+#ifdef CONFIG_XEN=0A if (unlikely(vma->v= m_ops && vma->vm_ops->unmap))=0A vma->vm_ops->unmap(vma);=0A= +#endif=0A }=0A =0A /*=0A@@ -1966,7 +1968,7 @@ EXPORT_SYMBOL(do_brk);=0A = void exit_mmap(struct mm_struct *mm)=0A {=0A struct mmu_gather = *tlb;=0A- struct vm_area_struct *vma_tmp, *vma =3D mm->mmap;=0A+ = struct vm_area_struct *vma =3D mm->mmap;=0A unsigned long nr_accounted = =3D 0;=0A unsigned long end;=0A =0A@@ -1974,8 +1976,11 @@ void = exit_mmap(struct mm_struct *mm)=0A arch_exit_mmap(mm);=0A #endif=0A = =0A- for (vma_tmp =3D mm->mmap; vma_tmp; vma_tmp =3D vma_tmp->vm_next)= =0A- unmap_vma(vma_tmp);=0A+#ifdef CONFIG_XEN=0A+ for (; = vma; vma =3D vma->vm_next)=0A+ unmap_vma(vma);=0A+ vma =3D = mm->mmap;=0A+#endif=0A =0A lru_add_drain();=0A flush_cache_mm(mm);= =0A --=__PartB485F160.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 --=__PartB485F160.0__=-- From xen-devel-bounces@lists.xen.org Wed Aug 01 09:35:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 09:35:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwVKC-0001C6-8q; Wed, 01 Aug 2012 09:34:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwVKA-0001C1-Ot for xen-devel@lists.xen.org; Wed, 01 Aug 2012 09:34:38 +0000 Received: from [85.158.143.35:32204] by server-2.bemta-4.messagelabs.com id 33/4D-17938-E28F8105; Wed, 01 Aug 2012 09:34:38 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1343813614!16871342!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjEzMjU=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3548 invoked from network); 1 Aug 2012 09:33:37 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Aug 2012 09:33:37 -0000 X-IronPort-AV: E=Sophos;i="4.77,693,1336363200"; d="scan'208";a="33174790" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Aug 2012 05:33:34 -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, 1 Aug 2012 05:33:33 -0400 Received: from andrewcoop.uk.xensource.com ([10.80.2.18]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SwVJ7-0004fa-Ip; Wed, 01 Aug 2012 10:33:33 +0100 Message-ID: <5018F7ED.3010100@citrix.com> Date: Wed, 1 Aug 2012 10:33:33 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Jan Beulich References: <20504.3594.340410.435942@mariner.uk.xensource.com> <5018FBB60200007800091CCB@nat28.tlf.novell.com> In-Reply-To: <5018FBB60200007800091CCB@nat28.tlf.novell.com> X-Enigmail-Version: 1.4.3 Cc: "Keir \(Xen.org\)" , Ian Jackson , Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 4 of 5] xen/makefile: Allow XEN_CHANGESET to be set externally X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/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/08/12 08:49, Jan Beulich wrote: >>>> On 31.07.12 at 18:55, Ian Jackson wrote: >> Andrew Cooper writes ("[PATCH 4 of 5] xen/makefile: Allow XEN_CHANGESET to be >> set externally"): >> .. >>> diff -r 6db5c184a777 -r ae32690d0d74 xen/Makefile >>> --- a/xen/Makefile >>> +++ b/xen/Makefile >>> @@ -13,6 +13,7 @@ export BASEDIR := $(CURDIR) >>> export XEN_ROOT := $(BASEDIR)/.. >>> >>> EFI_MOUNTPOINT ?= /boot/efi >>> +XEN_CHANGESET ?= $(shell hg root &> /dev/null && hg parents --template >> "{date|date} {rev}:{node|short}" || echo "unavailable" ) >>> >>> .PHONY: default >>> default: build >>> @@ -107,7 +108,7 @@ include/xen/compile.h: include/xen/compi >>> -e 's/@@version@@/$(XEN_VERSION)/g' \ >>> -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \ >>> -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \ >>> - -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date} >> {rev}:{node|short}" >/dev/null && hg parents --template "{date|date} >> {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \ >>> + -e 's!@@changeset@@!$(XEN_CHANGESET)!g' \ >>> < include/xen/compile.h.in > $@.new >>> @grep \" .banner >> $@.new >>> @grep -v \" .banner >> We need to check how many times, and at which point, this gets >> executed, when this patch is applied. I think it's OK... > If in doubt, perhaps the better option would be to execute this > once unconditionally (via := assignment to a helper variable), or > to use := here but frame the assignment with some if construct > excluding it to be executed when the changeset was already > specified (assuming that an empty specification is pointless, > simply checking for it to be non-empty should suffice). > > Jan > The rule looks like: # compile.h contains dynamic build info. Rebuilt on every 'make' invocation. include/xen/compile.h: include/xen/compile.h.in .banner @sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \ So it should only be executed once (unless someone is messing around deleting compile.h) Having said that, even if it were executed more than once, there is no reasonable circumstance during which the contents of XEN_CHANGESET should change. -- 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 Aug 01 09:35:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 09:35:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwVKC-0001C6-8q; Wed, 01 Aug 2012 09:34:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwVKA-0001C1-Ot for xen-devel@lists.xen.org; Wed, 01 Aug 2012 09:34:38 +0000 Received: from [85.158.143.35:32204] by server-2.bemta-4.messagelabs.com id 33/4D-17938-E28F8105; Wed, 01 Aug 2012 09:34:38 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1343813614!16871342!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjEzMjU=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3548 invoked from network); 1 Aug 2012 09:33:37 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Aug 2012 09:33:37 -0000 X-IronPort-AV: E=Sophos;i="4.77,693,1336363200"; d="scan'208";a="33174790" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Aug 2012 05:33:34 -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, 1 Aug 2012 05:33:33 -0400 Received: from andrewcoop.uk.xensource.com ([10.80.2.18]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1SwVJ7-0004fa-Ip; Wed, 01 Aug 2012 10:33:33 +0100 Message-ID: <5018F7ED.3010100@citrix.com> Date: Wed, 1 Aug 2012 10:33:33 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Jan Beulich References: <20504.3594.340410.435942@mariner.uk.xensource.com> <5018FBB60200007800091CCB@nat28.tlf.novell.com> In-Reply-To: <5018FBB60200007800091CCB@nat28.tlf.novell.com> X-Enigmail-Version: 1.4.3 Cc: "Keir \(Xen.org\)" , Ian Jackson , Ian Campbell , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 4 of 5] xen/makefile: Allow XEN_CHANGESET to be set externally X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/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/08/12 08:49, Jan Beulich wrote: >>>> On 31.07.12 at 18:55, Ian Jackson wrote: >> Andrew Cooper writes ("[PATCH 4 of 5] xen/makefile: Allow XEN_CHANGESET to be >> set externally"): >> .. >>> diff -r 6db5c184a777 -r ae32690d0d74 xen/Makefile >>> --- a/xen/Makefile >>> +++ b/xen/Makefile >>> @@ -13,6 +13,7 @@ export BASEDIR := $(CURDIR) >>> export XEN_ROOT := $(BASEDIR)/.. >>> >>> EFI_MOUNTPOINT ?= /boot/efi >>> +XEN_CHANGESET ?= $(shell hg root &> /dev/null && hg parents --template >> "{date|date} {rev}:{node|short}" || echo "unavailable" ) >>> >>> .PHONY: default >>> default: build >>> @@ -107,7 +108,7 @@ include/xen/compile.h: include/xen/compi >>> -e 's/@@version@@/$(XEN_VERSION)/g' \ >>> -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \ >>> -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \ >>> - -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date} >> {rev}:{node|short}" >/dev/null && hg parents --template "{date|date} >> {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \ >>> + -e 's!@@changeset@@!$(XEN_CHANGESET)!g' \ >>> < include/xen/compile.h.in > $@.new >>> @grep \" .banner >> $@.new >>> @grep -v \" .banner >> We need to check how many times, and at which point, this gets >> executed, when this patch is applied. I think it's OK... > If in doubt, perhaps the better option would be to execute this > once unconditionally (via := assignment to a helper variable), or > to use := here but frame the assignment with some if construct > excluding it to be executed when the changeset was already > specified (assuming that an empty specification is pointless, > simply checking for it to be non-empty should suffice). > > Jan > The rule looks like: # compile.h contains dynamic build info. Rebuilt on every 'make' invocation. include/xen/compile.h: include/xen/compile.h.in .banner @sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \ So it should only be executed once (unless someone is messing around deleting compile.h) Having said that, even if it were executed more than once, there is no reasonable circumstance during which the contents of XEN_CHANGESET should change. -- 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 Aug 01 09:47:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 09:47:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwVVW-0001Pl-GR; Wed, 01 Aug 2012 09:46:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwVVV-0001Pg-7f for xen-devel@lists.xensource.com; Wed, 01 Aug 2012 09:46:21 +0000 Received: from [85.158.138.51:23090] by server-3.bemta-3.messagelabs.com id F3/04-08301-CEAF8105; Wed, 01 Aug 2012 09:46:20 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-7.tower-174.messagelabs.com!1343814379!20934277!1 X-Originating-IP: [94.23.245.208] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31782 invoked from network); 1 Aug 2012 09:46:19 -0000 Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208) by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Aug 2012 09:46:19 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by lnx3.fantu.it (Postfix) with ESMTP id C38F64018E2 for ; Wed, 1 Aug 2012 11:46:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it Received: from lnx3.fantu.it ([127.0.0.1]) by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRDMJd468-oy for ; Wed, 1 Aug 2012 11:46:18 +0200 (CEST) Received: from [192.168.178.50] (host73-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: prova@fantu.it) by lnx3.fantu.it (Postfix) with ESMTPSA id F1B754017B0 for ; Wed, 1 Aug 2012 11:46:17 +0200 (CEST) Message-ID: <5018FAE5.6070305@tiscali.it> Date: Wed, 01 Aug 2012 11:46:13 +0200 From: Fabio Fantoni User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Bug report about Windows 7 pro 64 bit domU on xen-unstable dom0 with qemu traditional X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: fantonifabio@tiscali.it List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8250863752639961411==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Questo è un messaggio firmato digitalmente in formato MIME. --===============8250863752639961411== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090008010005060308030904" Questo è un messaggio firmato digitalmente in formato MIME. --------------ms090008010005060308030904 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Because the save / restore and cd-insert on qemu-xen for now are not=20 working I had to fall back onqemu-xen-traditional. Dom0 is Wheezy 64 bit with xen 4.2.0-rc1 from source I tested Windows 7 pro 64 bit domU with gplpv (last build 357). xl create is working xl shutdown is working vnc is working, but with vfb line on configuration file is not working save/restore is working but on restore network is up but not working cdrom is not working, see empty device also if there is cdrom After there are the content of domU configuration file and log, if you=20 need more information tell me and I will post it. -------------------------------------------------------------------------= ----------------------- /etc/xen/W7.cfg -------------------------------------------------------------------------= ----------------------- name=3D'W7' builder=3D"hvm" memory=3D2048 vcpus=3D2 vif=3D['bridge=3Dxenbr0'] #vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit'] disk=3D['/mnt/vm/disks/W7.disk1.xm,raw,hda,rw','/dev/sr0,raw,hdb,ro,cdrom= '] boot=3D'cd' device_model_version=3D"qemu-xen-traditional" vnc=3D1 vncunused=3D1 vnclisten=3D"0.0.0.0" keymap=3D"it" #spice=3D1 #spicehost=3D"0.0.0.0" spiceport=3D6000 #spicepasswd=3D'test' #spicedisable_ticketing=3D1 #spiceagent_mouse =3D 0 #on_poweroff=3D"destroy" on_reboot=3D"restart" on_crash=3D"destroy" #stdvga=3D0 #qxl=3D1 -------------------------------------------------------------------------= ----------------------- -------------------------------------------------------------------------= ----------------------- /var/log/xen/qemu-dm-W7.log -------------------------------------------------------------------------= ----------------------- domid: 9 -videoram option does not work with cirrus vga device model. Videoram=20 set to 4M. Using file /dev/xen/blktap-2/tapdev0 in read-write mode Using file /dev/sr0 in read-only mode Watching /local/domain/0/device-model/9/logdirty/cmd Watching /local/domain/0/device-model/9/command Watching /local/domain/9/cpu qemu_map_cache_init nr_buckets =3D 10000 size 4194304 shared page at pfn feffd buffered io page at pfn feffb Guest uuid =3D 6dd9db74-ec31-47a4-a2af-43e382d2ec21 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/9/xen_extended_power_mgmt): read err= or xs_read(): vncpasswd get error.=20 /vm/6dd9db74-ec31-47a4-a2af-43e382d2ec21/vncpasswd. medium change watch on `hdb' (index: 1): /dev/sr0 I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 Log-dirty: no command yet. I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 vcpu-set: watch node error. xs_read(/local/domain/9/log-throttling): read error qemu: ignoring not-understood drive `/local/domain/9/log-throttling' medium change watch on `/local/domain/9/log-throttling' - unknown=20 device, ignored 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. Unknown PV product 2 loaded in guest PV driver build 1 region type 1 at [c100,c200). region type 0 at [f3001000,f3001100). squash iomem [f3001000, f3001100). -------------------------------------------------------------------------= ----------------------- --------------ms090008010005060308030904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Firma crittografica S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV 10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2 YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8 h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1 kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8 oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+ qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1 XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEyMDgwMTA5NDYxM1owIwYJKoZIhvcNAQkEMRYEFBA0Lk4SYZz1pEhOnwPbjEjz +4ZFMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAfFN3ReNQBhevfSpAfTyYelXv 0WFNAlYO1jYp+MCoroN68KmfyVUu+C/Ff++ZdVpZaeBhfm8zddQq6bhTzfMt10FcZn6qL0Nk U8H2YhE0TkM58RkrnaExlTQbTOGIuIW2IvfLELo4V0UE+LPKE4YN2cy39Idq1HK4/97sKNJU lWyVzoPnSL/7VZ6NqAfiPuQvp3kRz33mqExTmQWiBoScy01Q+1YPXCY2uklvR6ZtCpQHTEM5 Pxl+0N96DmDcQIfanzVuWeU0VEEzFKUr/RGu4+k8/4YKXaAwwdZ25LnphsyKuqDtx+jUb9jP vaH85xacohWAPk87ZZ09CCw/L9MjrAAAAAAAAA== --------------ms090008010005060308030904-- --===============8250863752639961411== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8250863752639961411==-- From xen-devel-bounces@lists.xen.org Wed Aug 01 09:47:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 09:47:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwVVW-0001Pl-GR; Wed, 01 Aug 2012 09:46:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwVVV-0001Pg-7f for xen-devel@lists.xensource.com; Wed, 01 Aug 2012 09:46:21 +0000 Received: from [85.158.138.51:23090] by server-3.bemta-3.messagelabs.com id F3/04-08301-CEAF8105; Wed, 01 Aug 2012 09:46:20 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-7.tower-174.messagelabs.com!1343814379!20934277!1 X-Originating-IP: [94.23.245.208] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31782 invoked from network); 1 Aug 2012 09:46:19 -0000 Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208) by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Aug 2012 09:46:19 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by lnx3.fantu.it (Postfix) with ESMTP id C38F64018E2 for ; Wed, 1 Aug 2012 11:46:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it Received: from lnx3.fantu.it ([127.0.0.1]) by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRDMJd468-oy for ; Wed, 1 Aug 2012 11:46:18 +0200 (CEST) Received: from [192.168.178.50] (host73-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: prova@fantu.it) by lnx3.fantu.it (Postfix) with ESMTPSA id F1B754017B0 for ; Wed, 1 Aug 2012 11:46:17 +0200 (CEST) Message-ID: <5018FAE5.6070305@tiscali.it> Date: Wed, 01 Aug 2012 11:46:13 +0200 From: Fabio Fantoni User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Bug report about Windows 7 pro 64 bit domU on xen-unstable dom0 with qemu traditional X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: fantonifabio@tiscali.it List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8250863752639961411==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Questo è un messaggio firmato digitalmente in formato MIME. --===============8250863752639961411== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090008010005060308030904" Questo è un messaggio firmato digitalmente in formato MIME. --------------ms090008010005060308030904 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Because the save / restore and cd-insert on qemu-xen for now are not=20 working I had to fall back onqemu-xen-traditional. Dom0 is Wheezy 64 bit with xen 4.2.0-rc1 from source I tested Windows 7 pro 64 bit domU with gplpv (last build 357). xl create is working xl shutdown is working vnc is working, but with vfb line on configuration file is not working save/restore is working but on restore network is up but not working cdrom is not working, see empty device also if there is cdrom After there are the content of domU configuration file and log, if you=20 need more information tell me and I will post it. -------------------------------------------------------------------------= ----------------------- /etc/xen/W7.cfg -------------------------------------------------------------------------= ----------------------- name=3D'W7' builder=3D"hvm" memory=3D2048 vcpus=3D2 vif=3D['bridge=3Dxenbr0'] #vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit'] disk=3D['/mnt/vm/disks/W7.disk1.xm,raw,hda,rw','/dev/sr0,raw,hdb,ro,cdrom= '] boot=3D'cd' device_model_version=3D"qemu-xen-traditional" vnc=3D1 vncunused=3D1 vnclisten=3D"0.0.0.0" keymap=3D"it" #spice=3D1 #spicehost=3D"0.0.0.0" spiceport=3D6000 #spicepasswd=3D'test' #spicedisable_ticketing=3D1 #spiceagent_mouse =3D 0 #on_poweroff=3D"destroy" on_reboot=3D"restart" on_crash=3D"destroy" #stdvga=3D0 #qxl=3D1 -------------------------------------------------------------------------= ----------------------- -------------------------------------------------------------------------= ----------------------- /var/log/xen/qemu-dm-W7.log -------------------------------------------------------------------------= ----------------------- domid: 9 -videoram option does not work with cirrus vga device model. Videoram=20 set to 4M. Using file /dev/xen/blktap-2/tapdev0 in read-write mode Using file /dev/sr0 in read-only mode Watching /local/domain/0/device-model/9/logdirty/cmd Watching /local/domain/0/device-model/9/command Watching /local/domain/9/cpu qemu_map_cache_init nr_buckets =3D 10000 size 4194304 shared page at pfn feffd buffered io page at pfn feffb Guest uuid =3D 6dd9db74-ec31-47a4-a2af-43e382d2ec21 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/9/xen_extended_power_mgmt): read err= or xs_read(): vncpasswd get error.=20 /vm/6dd9db74-ec31-47a4-a2af-43e382d2ec21/vncpasswd. medium change watch on `hdb' (index: 1): /dev/sr0 I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 Log-dirty: no command yet. I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 vcpu-set: watch node error. xs_read(/local/domain/9/log-throttling): read error qemu: ignoring not-understood drive `/local/domain/9/log-throttling' medium change watch on `/local/domain/9/log-throttling' - unknown=20 device, ignored 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. Unknown PV product 2 loaded in guest PV driver build 1 region type 1 at [c100,c200). region type 0 at [f3001000,f3001100). squash iomem [f3001000, f3001100). -------------------------------------------------------------------------= ----------------------- --------------ms090008010005060308030904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Firma crittografica S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV 10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2 YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8 h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1 kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8 oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+ qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1 XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEyMDgwMTA5NDYxM1owIwYJKoZIhvcNAQkEMRYEFBA0Lk4SYZz1pEhOnwPbjEjz +4ZFMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAfFN3ReNQBhevfSpAfTyYelXv 0WFNAlYO1jYp+MCoroN68KmfyVUu+C/Ff++ZdVpZaeBhfm8zddQq6bhTzfMt10FcZn6qL0Nk U8H2YhE0TkM58RkrnaExlTQbTOGIuIW2IvfLELo4V0UE+LPKE4YN2cy39Idq1HK4/97sKNJU lWyVzoPnSL/7VZ6NqAfiPuQvp3kRz33mqExTmQWiBoScy01Q+1YPXCY2uklvR6ZtCpQHTEM5 Pxl+0N96DmDcQIfanzVuWeU0VEEzFKUr/RGu4+k8/4YKXaAwwdZ25LnphsyKuqDtx+jUb9jP vaH85xacohWAPk87ZZ09CCw/L9MjrAAAAAAAAA== --------------ms090008010005060308030904-- --===============8250863752639961411== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8250863752639961411==-- From xen-devel-bounces@lists.xen.org Wed Aug 01 09:59:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Aug 2012 09:59:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwVhW-0001ZW-Nn; Wed, 01 Aug 2012 09:58:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1SwVhU-0001ZR-Ji for xen-devel@lists.xen.org; Wed, 01 Aug 2012 09:58:45 +0000 Received: from [85.158.143.99:12269] by server-1.bemta-4.messagelabs.com id DE/8C-24392-3DDF8105; Wed, 01 Aug 2012 09:58:43 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1343815119!29389983!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNjg2MjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30320 invoked from network); 1 Aug 2012 09:58:40 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 1 Aug 2012 09:58:40 -0000 X-IronPort-AV: E=Sophos;i="4.77,693,1336363200"; d="scan'208";a="203779554" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Aug 2012 05:57: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; Wed, 1 Aug 2012 05:57:38 -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 1SwVgP-00055K-UY; Wed, 01 Aug 2012 10:57:37 +0100 MIME-Version: 1.0 X-Mercurial-Node: 84f0686ebcbfb0fa3a437def65513038be389736 Message-ID: <84f0686ebcbfb0fa3a43.1343815057@cosworth.uk.xensource.com> User-Agent: Mercurial-patchbomb/1.6.4 Date: Wed, 1 Aug 2012 10:57:37 +0100 From: Ian Campbell To: xen-devel@lists.xen.org Cc: ian.jackson@citrix.com, Roger Pau Monne Subject: [Xen-devel] [PATCH V2] libxl: support custom block hotplug scripts X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: 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 1343815041 -3600 # Node ID 84f0686ebcbfb0fa3a437def65513038be389736 # Parent 006588b1bbb609186df45770a3c16d3028b54778 libxl: support custom block hotplug scripts These are provided using the "script=" syntax described in docs/misc/xl-disk-configuration.txt. The existing hotplug scripts currently conflate two different concepts, namely that of making a datapath available in the backend domain (logging into iSCSI LUNs and the like) and that of actually connecting that datapath to a Xen backend path (e.g. writing "physical-device" node in xenstore to bring up blkback). For this reason the script support implemented here is only supported in conjunction with backendtype=phy. Eventually we hope to rework the hotplug scripts to separate the to concepts, but that is not 4.2 material. In addition there are some other subtleties: - Previously in the blktap case we would add "script = .../blktap" to the backend flex array, but then jumped to the PHY case which added "script = .../block" too. The block one takes precendence since it comes second. This was, accidentally, correct. The blktap script is for blktap1 devices and not blktap2 devices. libxl completely manages the blktap2 side of things without resorting to hotplug scripts and creates a blkback device directly. Therefore the "block" script is always the correct one to call. Custom script are not supported in this context. - libxl should not write the "physical-device" node. This is the responsibility of the block script. Writing the "physical-device" node in libxl basically completely short-cuts the standard block hotplug script which uses "physical-device" to know if it has run already or not. In the case of more complex scripts libxl cannot know the right value to write here anyway, in particular the device may not exist until after the script is called. This change has the side effect of re-enabling the checks for device sharing aspect of the default block script, which I have tested and which now cause libxl to properly abort now that libxl properly checks for hotplug script errors. There is no sharing check for blktap2 since even if you reuse the same vhd the resulting tap device is different. I would have preferred to simply write the "physical-device" node for the blktap2 case but the hotplug script infrastructure is not currently setup to handle LIBXL__DEVICE_KIND_VBD devices without a hotplug script (backendtype phy and tap both end up as KIND_VBD). Changing this was more surgery than I was happy doing for 4.2 and therefore I have simply hardcoded to the block script for the LIBXL_DISK_BACKEND_TAP case. - libxl__device_disk_set_backend running against a phy device with a script cannot stat the device to check its properties since it may not exist until the script is run. Therefore I have special cased this in disk_try_backend to simply assume that backend == phy is always ok if a script was configured. Similarly the other backend types are always rejected if a script was configured. Note that the reason for implementing the default script behaviour in device_disk_add instead of libxl__device_disk_setdefault is because we need to be able to tell when the script was user-supplied rather than defaulted by libxl in order to correctly implement the above. The setdefault function must be idempotent so we cannot simply update disk->script. I suspect that for 4.3 a script member should be added to libxl__device, this would also help in the case above of handling devices with no script in a consistent manner. This is not 4.2 material. - When the block script falls through and shells out to a block-$type script it used to pass "$node" however the only place this was assigned was in the remove+phy case (in which case it contains the file:// derived /dev/loopN device), and in that case the script exits without falling through to the block-$type case. Since libxl never creates a type other than phy this never happens in practice anyway and we now call the correct block-$type script directly. But fix it up anyway since it is confusing. - The block-nbd and block-enbd scripts which we supply appear to be broken WRT the hotplug calling convention, in that they seem to expect a command line parameter (perhaps the $node described above) rather than reading the appropriate node from xenstore. I rather suspect this was broken by 7774:e2e7f47e6f79 in November 2005. I think it is safe to say no one is using these scripts! I haven't fixed this here. It would be good to track down some working scripts and either incorproate them or defer to them in their existing home (e.g. if they live somewhere useful like the nbd tools package). - Added a few block script related entries to check-xl-disk-parse from http://backdrift.org/xen-block-iscsi-script-with-multipath-support and http://lists.linbit.com/pipermail/drbd-user/2008-September/010221.html / http://www.drbd.org/users-guide-emb/s-xen-configure-domu.html (and snuck in another interesting empty CDROM case) This highlighted two bugs in the libxlu disk parser handling of the deprecated "